Junio C Hamano <gitster@xxxxxxxxx> writes:
>> Which other refs that aren't really refs should also be supported? The
>> JGit source code suggests that MERGE_HEAD should also be special
>> cased?
>
> I'd think all .git/${SOMETHING}_HEAD are of transitory nature that
> can be left as simple on-disk files that are read (and preferrably
> written---except for FETCH_HEAD for obvious reasons) as if they are
> loose refs handled by files backend.
Sorry for flipping and flopping. The above goes directly against
the spirit of 09743417 (Modify pseudo refs through ref backend
storage, 2020-07-27). I still think .git/${SOMETHING}_HEAD except
for FETCH_HEAD should be written and read via the ref subsystem, but
I was wrong to say that it should always be done via the files
backend. There is no reason to insist on the use of files backend
here.
> It probably makes sense not to
> even write reflog entries for them---it is not like the MERGE_HEAD
> I see now in .git/ directory is an updated version of MERGE_HEAD I
> had there yesterday. "git log -g MERGE_HEAD" gives no interesting
> information.
This still is true, but that is pretty much orthogonal to which
backend is used.
> If the octopus merge does not finish correctly (e.g. due to
> conflicts), with "git reset --hard", we can recover to the original
> state and re-attempt the opeation with "git merge FETCH_HEAD". Such
> a merge using FETCH_HEAD will produce an octopus merge.
>
> Which means that at least "git merge", FETCH_HEAD is not just a
> regular ref where you can ask what object it points at and it gives
> you a single object name back.
>
> But to other commands like "git log master..FETCH_HEAD", it acts as
> if there is only one object recorded.
All of which means FETCH_HEAD is special and we may not want to
burden the special casing of it to newer backends.
