Re: [PATCH] Update the documentation for git-merge-base

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]