Re: [PATCH 2/2] ref-filter: support filtering of operational refs

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2024, 16:02 UTC
Message-ID: <xmqqsf3ebe1l.fsf@gitster.g>
In-Reply-To: <ZZWCXFghtql4i4YE@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 11 quoted lines

> The downside of an empty prefix is that you wouldn't be able to filter
> refs outside of the "refs/" hierarchy in case we'd use the empty prefix.
> A better alternative would be to use "/" as an indicator that you want
> to list refs outside of "refs/". That'd allow for more flexible queries:
>
>   - "/" prints all refs and pseudo refs, even those outside of the
>     "refs/" hierarchy.
>
>   - "/refs" prints your normal refs.
>
>   - "/something/else" prints refs in "$GIT_DIR/something/else".

I do not get this at all, sorry. What makes your "/" cover "refs/" but not "something/"? Unless you have some rule that special cases "/" to apply the "hierarchy prefix" matching rule unevenly, that is not possible. So you can easily lose the "/" all of your above patterns share, go back to what I showed, and apply the morally equivalent special case to an empty prefix and you'd be OK.

In any case, I do not think supporting anything other than pseudorefs and HEAD outside "refs/" is a good idea to begin with (the "worktrees/$name/" example), and requiring that all normal references live inside "refs/" hierarchy is a good idea, so all of the above is moot, I would say.

Thanks.