On Wed, May 07, 2014 at 03:40:28PM +0000, Jim Garrison wrote: > During my initial self-education I came across the maxim "don't pull, > fetch+merge instead" and have been doing that. I think I followed > most of the "pull is (mostly) evil" discussion but one facet still > puzzles me: the idea that pull will do a merge "in the wrong > direction" sometimes. > > Do I understand correctly that this occurs only in the presence of > multiple remotes? No, it does not have to do with multiple remotes. It is about "X merged into Y" versus "Y merged into X". The ordering of parents in a merge doesn't matter for the merge result, but git must choose some order, and it always uses your current HEAD first, and then the commit you are merging second (and so on, in an octopus merge). As a result, you can use "git log --first-parent" to follow the line of development that always got merged into. In a strict topic-branch workflow like git.git, this will show you just what happened on master: a linear sequence of merges of topic branches, with occasional direct-to-master commits like version bumps. For an integrator who is pulling from other people, "git pull bob topic" from "master" does the right thing: master is the first parent, and topic is the second parent. For somebody with a centralized repo who follows the "push was a non-fastforward, so pull then push" advice, the merge between their work and master will be "backwards". The merge commit will have upstream's work (i.e., "master") merged into their topic. Following --first-parent will walk down their work instead of the merge commits on master. Does that explain it? -Peff -- 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