Re: How does git follow branch history across a merge commit?

"Steven E. Harris" [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

If you merge competition into your master, the resulting commit will
have your master as its first parent.  If check out competition and
merge master in your example, the resulting merge will have
compatition as the first parent.

I see, having run a few more experiments to confirm this.

I missed the point that merge commits are not "predecessor neutral";
they apparently have a bias indicating "/this branch/ received content
from /that branch/ (or /those branches/)".

We are in principle pretty much neutral, but in certain places you
obviously cannot avoid tiebreaking.  A commit object has to record parents
in a bytestream in its representation, and inevitably one parent must come
before another one.

You also must give your users some way to refer to each of its parents, so
naturally we count from one, and call them $it^ (== $it^1), $it^2, etc.
We do not have "$it^?" that lets you pick its parents at random, as we
haven't found a good use case for such a feature.

One place we tiebreak favoring earlier parents over later ones, even
though there is no logical reason to do so, is merge simplification [*1*].
When more than one parents have the same tree, with respect to pathspec
given, while traversing the history, we pick the earliest one, because
that is just as good as choosing one at random, and would give us a
reproducible result.  For a similar reason, when blame follows a merge
from identical parents, it assigns blame to earlier parents.

And at the end-user workflow level, people tend to think "I merge others
work into mine", so the log family of commands have --first-parent option
to follow only that ancestry, but that logic kicks in only while browsing,
not while building histories.

[Footnote]

*1* If you do not know what a merge simplification is, refer to e.g.
http://gitster.livejournal.com/35628.html and notice there is a place
where we follow "a parent that is the same as the merge result".

Junio C Hamano [off-list ref] writes:

*1* If you do not know what a merge simplification is, refer to e.g.
http://gitster.livejournal.com/35628.html and notice there is a place
where we follow "a parent that is the same as the merge result".

I read this article today with great interest. Had I known of it
beforehand, it would have changed some of my flawed assumptions evident
in my post. Thanks for writing that. I'll be looking into the rest of
the articles there to learn more.

-- 
Steven E. Harris