From: Phillip Wood Date: Tue, 06 Feb 2024 13:56:43 GMT Subject: Re: What's cooking in git.git (Feb 2024, #02; Fri, 2) Message-ID: In-Reply-To: Hi Junio On 05/02/2024 23:20, Junio C Hamano wrote: > Phillip Wood 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/