On Tue, 16 May 2006, Linus Torvalds wrote: > > I don't think you can be more specific, or do a better job. The definition > of "most recent" is arbitrary, of course - and going by commit date is > just _one_ way to order them, but it happens to be an easy one, and one > that is as good as any other choice. Side note: since LCA's are (by definition) never going to have a direct graph relationship, there is obviously no ordering enforced by the graph itself. So they're all unordered in the graph sense, but you could use other measures of "distance" in the graph. Example other orderings that we _could_ do, and I considered (some purely graph based, others based on content): - order by number of commits between the LCA and the two commits that we are trying to find the LCA for (the "tips"). - order by diff size between the LCA and the tips - order by lack of conflicts between the LCA and the tips. however, none of the alternate orderings really seem to make a lot of sense. The date-based one trumps them all by being straightforward and simple to both implement and explain. And iirc, I actually verified that it happened to pick the "better" one for at least one of my tests when using the old stupid straigth three-way merge, so I think it was actually objectively a good measure at least once. Anybody who cares can obviously always just do "git-merge-base --all" and do their own sorting for the (relatively unlikely) case that you get more than one parent. Anyway, just out of interest I just did some statistics using some shell scripts: - For the current kernel tree, of 1857 merges, only 17 had more than one merge base (and none had more than two): 1840 o 17 oo - In contrast, for git (current master branch), the numbers are 35 out of 540, and there are lots of merges with many LCA's: 505 o 15 oo 13 ooo 2 oooo 3 ooooo 2 ooooooo I think the difference is that Junio does a lot of these branches where he keeps on pulling from them, and never syncs back (which is a great workflow). In contrast, the kernel tends to try to avoid that because the history gets messy enough as it is ;) Anyway, the two commits that apparently have seven (!) LCA's in the git tree should probably be checked out. They are probably a good thing to see if git-merge-base really _really_ does the right thing, and whether they really are true LCA's. They are commits ad0b46bf.. and e6a933bd.. respectively. Linus - : 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