"Steven E. Harris" <seh@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> 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". -- 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