Karthik Nayak <karthik.188@xxxxxxxxx> writes:
> 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.
It would not begin with 40-hex, though. If I were doing this,
perhaps I'd say we should first split is_pseudoref_syntax() that is
overly loose into to classes (e.g. "caps with underscores that ends
with HEAD" and everything else), silently reject false positives
among the latter class. Then we rename those that are misnamed
(there should be only few, like AUTO_MERGE that should be a
pseudoref but named without _HEAD; I do not think of anything that
ends with _HEAD that is not a ref) over time and drop the latter
class.
> 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?
"list pseudorefs in addition to things below refs/"? Sounds OK to
me as a feature.
However, "--all" does not mean that in the context of "git log"
family of commands. Over there, it means "not just --branches,
--tags, and --remotes, but everything" which is still limited below
"refs/".
As "git for-each-ref" takes pattern that is prefix match, e.g.,
$ git for-each-ref refs/remotes/
shows everything like refs/remotes/origin/main that begins with
refs/remotes/, I wonder if
$ git for-each-ref ""
should mean what you are asking for. After all, "git for-each-ref"
does *not* take "--branches" and others like "git log" family to
limit its operation to subhierarchy of "refs/" to begin with.
