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

From: Karthik Nayak <karthik.188@gmail.com>
Date: Dec 22, 2023, 14:05 UTC
Message-ID: <CAOLa=ZRedfBUjukbN8dFT9CZETe4pz1UR+eWfJwORWuMHSk0Rw@mail.gmail.com>
In-Reply-To: <xmqqzfy3l270.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> We have pseudoref (those all caps files outside the refs/ hierarchy)
> as an official term defined in the glossary, and Patrick's reftable
> work based on Han-Wen's work revealed the need to treat FETCH_HEAD
> and MERGE_HEAD as "even more pecurilar than pseudorefs" that need
> different term (tentatively called "special refs").  Please avoid
> coming up with yet another random name "operational" without
> discussing.
>

I totally agree with the term usage and will switch to "pseudorefs".

Show 9 quoted lines

> With a quick look at the table in this patch, "pseudorefs" appears
> to be the closest word that people are already familiar with, I
> think.  A lot more reasonable thing to do may be to scan the
> $GIT_DIR for files whose name satisfy refs.c:is_pseudoref_syntax()
> and list them, instead of having a hardcoded list of these special
> refs.  In addition, when reftable and other backends that can
> natively store things outside refs/ hierarchy is in use, they ought
> to know what they have so enumerating these would not be an issue
> for them without having such a hardcoded table of names.

Thanks for that, I did play around with trying to find files which could be refs in the $GIT_DIR, but the issue is that there will be false positives. e.g. `COMMIT_EDITMSG` could be confused for a pseudoref (passes is_pseudoref_syntax()) and it could potentially also contain a commit-ish value.

While you're here, I wonder if you have any thoughts on the last block of my first mail.

> Over this, I'm also curious on what the mailing list thinks about
> exposing this to the client side. Would an `--all` option for
> git-for-each-ref(1) be sufficient?
>

Thanks
- Karthik