Junio C Hamano <gitster@xxxxxxxxx> writes: > 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". > 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
