On Mon, Feb 16, 2009 at 11:43 PM, Jay Soffian <jaysoffian@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
