Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes:
>> >> 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.
>> "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.
