Re: FETCH_HEAD question

On Mon, Feb 16, 2009 at 11:43 PM, Jay Soffian [off-list ref] wrote:

I did this the other day out of mild curiosity:

$ git fetch
$ git merge FETCH_HEAD

Which did something, but not something that was at all useful. It
merges in the first ref listed in FETCH_HEAD. It does not appear to be
an accident that it does this, as git merge has special treatment for
FETCH_HEAD to generate the merge message.

Why does this behavior exist? Historical?

To be clear, this seems only to be useful if you are only fetching a
single branch from remote. Otherwise the branch which you end up
merging (the first alphabetically) may very well not be what the
current checked-out branch is based on.

So to work correctly in the case of pulling multiple branches,
dwim_ref() would have to return the sha1 corresponding to the single
line in FETCH_HEAD that is not marked "not-for-merge" and git merge
would similarly need to use that line for the merge message. Or git
fetch would need to place the non-not-for-merge ref first in the file.

I found this in the archives, but it didn't really answer my question
about why it got implemented the current way:

http://thread.gmane.org/gmane.comp.version-control.git/42788/focus=42850

j.