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

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 3, 2024, 16:17 UTC
Message-ID: <ZZWIlx-9D2r9AfDW@tanuki>
In-Reply-To: <xmqqsf3ebe1l.fsf@gitster.g>

On Wed, Jan 03, 2024 at 08:02:46AM -0800, Junio C Hamano wrote:

Show 16 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 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/"?

It does cover "something/". But...

Show 5 quoted lines

> 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.

... I think you're right -- I was arguing under the misassumption that the typical rev-parse rules kicked in for git-for-each-ref(1) (e.g. matching "heads/foo" to "refs/heads/foo"). But they don't, so my point indeed becomes moot and I see what you're getting at now and agree with you.

Show 5 quoted lines

> 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.

Yeah, I'm on the same page: anything outside of "refs/" should not be supported. But the problem is that tools like git-update-ref(1) don't enforce this, so something like `git update-ref foo/bar HEAD` happily creates "$GIT_DIR/foo/bar". And I bet there are other ways to write refs at arbitrary paths.

With the files backend it's easy to see that this was created and can be rectified. But with the reftable library you wouldn't be able to learn about the existence of this ref at all if we ignored anything but pseudo-refs and refs prefixed with "refs/".

So while I agree that we shouldn't endorse such refs, we need to at least give an escape hatch in case such refs end up in the refdb anyway.

Patrick