Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2020, 20:07 UTC
Message-ID: <xmqqh7tjv6hb.fsf@gitster.c.googlers.com>
In-Reply-To: <CAFQ2z_O1sRm-_SNP=-GvgNLqB+qgf6k9YVfbF1XCAmFWdeX6Ew@mail.gmail.com>

Han-Wen Nienhuys <hanwen@google.com> writes:

Show 19 quoted lines

>> >> As the file is quite different from all the other pseudo references
>> >> in that it needs to store more than one object name and in that each
>> >> ref in it needs more than just the object name, I doubt that it
>> >> makes much sense to enhance the refs API so that its requirements
>> >> can be covered.
>> >
>> > I agree. Do we ever pretend that FETCH_HEAD is a ref today?
>>
>> "git rev-parse FETCH_HEAD", "git show FETCH_HEAD" etc. all should keep
>> working, so in that sense, it is treated as a ref.
>
> I added this to the last version of the full reftable patch series
> that I posted, as patches
> "Split off reading loose ref data in separate function" and "Read
> FETCH_HEAD as loose ref".
>
> 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. 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.

Show 9 quoted lines

>> "git merge FETCH_HEAD" is an interesting case---I haven't thought it
>> through.
>>
>> What should happen after "git pull origin foo bar" attempts to grab
>> two branches and make an octopus merge into the branch currently
>> checked out, and then "git reset --hard && git merge FETCH_HEAD" is
>> given?
>
> I don't understand this question.

The request "git pull origin foo bar" is "grab the tip of 'foo' and 'bar' branches from remote whose name is 'origin'; merge these two commits into the commit that I have checked out".

To fulfill the request, "git pull" runs "git fetch", and the latter leaves two lines of interest in .git/FETCH_HEAD file. Each line lists the name of the object at the ref, an optional "not-for-merge" token (which in this case does not exist, as both records are for merging), and piece of human-readable text to describe where that object came from to help later step that computes the default message for the resulting merge commit.

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. That makes it an interesting case. Making it act as if "git log ^master origin/foo origin/bar" were given might be a "bugfix" to make it behave more "correctly", but I do not know how large a fallout such a change brings in.