2 messages, 1 author, 2016-06-15 · open the first message on its own page
From: Jay Soffian <hidden>
Date: 2016-06-15 22:46:13
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? j.
From: Jay Soffian <hidden>
Date: 2016-06-15 22:46:13
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.