From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id D07161F953 for ; Tue, 23 Nov 2021 03:36:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232838AbhKWDjP (ORCPT ); Mon, 22 Nov 2021 22:39:15 -0500 Received: from pb-smtp21.pobox.com ([173.228.157.53]:54327 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231868AbhKWDjO (ORCPT ); Mon, 22 Nov 2021 22:39:14 -0500 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 8FF0A1732A5; Mon, 22 Nov 2021 22:36:04 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=VQDzfVvtXNB8 mGWaObon1lk0Twkf8lnqJSWvhAbPCPo=; b=l86nl7J/EPvyReEJKBK/6Fr12ATF AkQD6xOmEi3GtjTE6cH5sRUe1WNiaQ7ylY4GRTQxQdlmuRoqBa3/x7++03KlJGV0 KO0kjII+z2gkQMRqkMfXV9gLp1hygUKxQkVXC24B3X8HYoJZGXA5dUhhwtAIp88O DjaosUO76C4Opug= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 88E001732A4; Mon, 22 Nov 2021 22:36:04 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [104.133.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 9395A1732A0; Mon, 22 Nov 2021 22:36:00 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Teng Long , git@vger.kernel.org, congdanhqx@gmail.com, peff@peff.net Subject: Re: [PATCH v3 1/1] ls-tree.c: support `--oid-only` option for "git-ls-tree" References: <6c15b4c176b7c03072fa59a4efd9f6fea7d62eae.1637567328.git.dyroneteng@gmail.com> <211123.86tug3wu8v.gmgdl@evledraar.gmail.com> <211123.868rxfwqdw.gmgdl@evledraar.gmail.com> Date: Mon, 22 Nov 2021 19:35:59 -0800 In-Reply-To: (Junio C. Hamano's message of "Mon, 22 Nov 2021 18:55:56 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 7A448BCC-4C0E-11EC-8724-98D80D944F46-77302942!pb-smtp21.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Junio C Hamano writes: > =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason writes: > >>> That is what I would call over-engineering that I would rather not >>> to have in low level plumbing. >>> ... >> We've got --format for for-each-ref and family (also branch etc.), and >> for the "log" family. > > But I didn't comment on them. ls-tree is a lot lower-level plumbing > where --format does not belong in my mind. There is a lot more practical reason why I'd prefer a less flexible and good enough interface. I can see, without coding it myself but from mere memory of how the code looked like, how such a "we allow you to choose which field to include, but you do not get to choose the order of fields or any other string in the output" can be done with minimum disruption to the existing code and without introducing a bug. On the other hand, I am fairly certain that anything more flexible than that will risk new bugs involved in any large shuffling of the code, which I am getting tired of. So there.