Re: [GSoC][RFC PATCH v4 3/5] builtin/refs: add list subcommand

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2025, 14:43 UTC
Message-ID: <xmqqseibm7ap.fsf@gitster.g>
In-Reply-To: <2d2f823d-6e85-44a0-85d2-d45d4dc287fc@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 20 quoted lines

> I find the behavior of for-each-ref quite confusing so I wonder if we
> really want to copy it to the new command. For example
>
>     git for-each-ref 'refs/h*'
>
> does not print anything but
>
>     git for-each-ref 'refs/heads/m*'
>
> prints all the branches beginning with m. Another example is
>
>     git for-each-ref 'refs/heads'
>
> prints all the branches but
>
>     git for-each-ref 'refs/heads*'
>
> prints nothing. To me it would be much easier to understand if the
> pattern always required an explicit wildcard (or possible always did a
> prefix match in the absence of a wildcard).

Thanks for raising this point.

One point you are wrong is 'refs/heads/m*'; it does not list all the branches that begin with "m". It will not show "refs/heads/mid/night" even though it may show "refs/heads/morning'.

I do not think we want to require wildcard (in other words, refs/heads/ and refs/heads that result in the prefix matching behaviour that is anchored at hierarchy boundary is a good thing, and we should not require refs/heads/* to get it).

As the "list the refs with various criteria" feature itself is shared with "refs list", it would make the entire system even more confusing if their criteria to choose which ones to show are different.

I _think_ the current selection criteria is basically the prefix match that is anchored at hierarchy boundary, and a single asterisk expands only to a single hierarchy element without crossing hierarchy boundary. It is very handy that refs/heads/* expands to the main integration branches (master, next, seen, maint-*) without showing pw/3.0-commentchar-auto-deprecation branch and others.

What does a double-asterisk currently do in these patterns? If it is not doing anything useful, perhaps we should make it match any letter, without getting constrained by hierarchy boundaries? IOW, a "fix" might be to make sure the following happens?

 - "refs/heads/m*" matches all local branches whose name starts with
   'm' like 'morning', but not the ones inside subhierarchies that
   start with 'm' like 'mid/night'.

 - "refs/heads/m**" matches all local branches whose name starts
   with 'm' and in the ones inside subhierarchies that start with
   'm'.

Thanks.