On Thu, Feb 10, 2022 at 5:36 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >> One thing that makes me worried somewhat is what I did not touch,
> >> namely, how pseudo refs are defined. I know MERGE_HEAD is very
> >> special and it may be impossible to coax it into refs API for
> >> writing, so the text there makes sense for it, but there are
> >> other all-caps-and-directly-under-dot-git-directory files like
> >> ORIG_HEAD and CHERRY_PICK_HEAD that are written using the refs
> >> API, so the description would have to be updated there.
> >
> > I'm not quite following; why would the description need to be updated?
> > Sure MERGE_HEAD is written without using the refs API, but we didn't
> > mention how the pseduorefs were written in the description, and all of
> > MERGE_HEAD, CHERRY_PICK_HEAD, ORIG_HEAD, REVERT_HEAD get written
> > per-worktree so doesn't "pseudorefs like MERGE_HEAD" cover it as far
> > as the reader is concerned?
>
> Here is how pseudo refs are defined.
>
> [[def_pseudoref]]pseudoref::
> Pseudorefs are a class of files under `$GIT_DIR` which behave
> like refs for the purposes of rev-parse, but which are treated
> specially by git. Pseudorefs both have names that are all-caps,
> and always start with a line consisting of a
> <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a
> pseudoref, because it is sometimes a symbolic ref. They might
refs.c says
if (is_pseudoref_syntax(refname))
return REF_TYPE_PSEUDOREF;
Ie. ref_type("HEAD") == REF_TYPE_PSEUDOREF
This may be partly my fault (commit 55dd8b910 "Make HEAD a PSEUDOREF
rather than PER_WORKTREE.").
