Re: FETCH_HEAD question

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, Feb 16, 2009 at 11:43 PM, Jay Soffian <jaysoffian@gmail.com> 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.