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