Re: Beginner question on "Pull is mostly evil"

[Jeff King <peff@peff.net>]

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