Re: [RFC PATCH 6/6] ls-tree: introduce '--pattern' option

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2022, 05:27 UTC
Message-ID: <xmqqbko6y2q5.fsf@gitster.g>
In-Reply-To: <xmqqtu20qinx.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> The hard-coded object IDs break the `linux-sha256` job, as pointed out in
>> https://github.com/git/git/blob/6ab7651d8669/whats-cooking.txt#L522-L537.
>>
>> Please squash this in to address this (Junio, please feel free to
>> cherry-pick this on top of `tl/ls-tree--pattern` to reduce the number of
>> CI failures):

After re-reading the patches, I am very much inclined to drop this topic, which does not add much value to the system and adds an odd corner case in the UI.

Who needs "git ls-tree --pattern='blob 486' HEAD" that is a synonym to "git ls-tree HEAD | grep 'blob 486'"? Should we end up adding the same option to "git ls-files", "git status", "git ls-remote", "git remote", "git branch --list", etc. for consistency?

This is simply insane and goes directly against the "one tool does one job well, and can be combined with other such tools via pipe", which is a key to scale the usability of a set of tools.