Re: FETCH_HEAD question

Jay Soffian <jaysoffian@gmail.com> writes:

In general, FETCH_HEAD is usable as an extended SHA-1, in that any file that is in .git/ and begins with [0-9a-f]{40} names that object. That is how "git log -p ..FETCH_HEAD" in my example worked.

The reason stripping of not-for-merge is done is to support a usage that is not so sane as well.

You can do a wildcard fetch that leaves full of not-for-merge entries in FETCH_HEAD, and then use FETCH_HEAD as an extended SHA-1 to merge the one that happens to be on the first line. "git merge" *could* in such a case produce:

	Merge commit $ugly_40_hexadecimal_name

to say that it merged that commit named by a random extended SHA-1, but it knows that FETCH_HEAD has better information than that. The line tells where you got that commit from. And that is recorded past not-for-merge marker (if exists, otherwise it is an empty string) that is enclosed by a HT on each side. This is a direct translation from the scripted version that did:

	sed -e 's/	not-for-merge	/		/' -e 1q

It is being overly nice to produce a sensible merge message, even when you asked it to do something not very sensible.

Now to something totally useless.

After reading the builtin-merge.c and original git-merge.sh (now in contrib/examples) script, I think it could have done something entirely different.

It could have done this instead.

	sed -e '/	not-for-merge	/d'

to learn the commits and their human-readable origins, and it could have tried to reproduce what "git pull" did when it invoked git-merge using that information. Then you could use this workflow:

	$ git pull <possibly with arguments>
        ... oops, conflicted and is very messy.
        ... I tried to resolve, but failed and made the mess even worse.
        ... Let's start over.
        $ git reset --hard
        ... FETCH_HEAD knows which refs are for merging
        $ git merge FETCH_HEAD

That is, no matter what the arguments were for the initial "git pull", what should be merged is recorded in FETCH_HEAD, and that is how you can retry the merge without refetching over the network.

But such a change makes FETCH_HEAD different from what it traditionally meant, and does that only to "git merge", making the result very inconsistent. For example, "git log ..FETCH_HEAD" will still use the object name on the first line, and it won't be a way to convince yourself that the changes are sensible and it is Ok to run "git merge FETCH_HEAD" anymore. So I do not think such a change will be an improvement.