Re: What's cooking in git.git (Feb 2024, #02; Fri, 2)

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Junio

On 05/02/2024 23:20, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
>> I'm concerned that the UI could use some improvement. If I understand
>> correctly the proposal is to make
>>
>> 	git for-each-ref
>>
>> and
>>
>> 	git for-each-ref ""
>>
>> behave differently so that the latter prints the pseudorefs from the
>> current worktree and the former does not.
> 
> I would actually think that is perfectly sensible.  The optional
> arguments for-each-ref name "filtering patterns" and you can view
> the behaviour of the command as using "refs/" as the default
> filtering pattern when nothing is given.  But it is easy to defeat
> the unfortunate and historical default filtering pattern, by saying
> "we do not limit to any hierarchy, anything goes" by giving "" as
> the prefix.

There is a logic to that if one ignores 
"refs/{main-worktree,worktrees/$worktree}/*" not being shown. As Patrick 
has pointed out the change in the handling of the empty prefix here is a 
breaking change though [1]. To me, the handling of the empty prefix 
feels inconsistent with the rest of the pattern space. The patterns "*" 
and "*_HEAD" don't match anything and there is no way to filter a subset 
of pseudorefs. If all we want is a way to show all the refs including 
pseudorefs in a worktree then I think an option to do that which errored 
out if a pattern is given would be a better approach. I'd prefer an 
option (say "--include-pseudorefs") that included pseudorefs in the list 
of refs to be filtered and allowed the user to filter them as they 
wanted. That way we could later add a "--all-worktrees" option that 
included refs/{main-worktree,worktrees/$worktree} in the list of refs to 
be filtered as well.

Best Wishes

Phillip

[1] https://lore.kernel.org/git/ZcHEmyvvMR_b_Idl@tanuki/