Re: [RFC, PATCH] A new merge algorithm (EXPERIMENTAL)

From: Linus Torvalds <torvalds@osdl.org>
Date: Aug 27, 2005, 00:38 UTC
Message-ID: <Pine.LNX.4.58.0508261730480.3317@g5.osdl.org>
In-Reply-To: <20050826184731.GA13629@c165.ib.student.liu.se>

On Fri, 26 Aug 2005, Fredrik Kuivinen wrote:

>
> In real numbers it is as follows: In Linus' kernel tree there are
> 5996 commits. 400 of those have more than one parent. Of those 400
> merge commits 4 have more than one shared head.

Ok, that's already interesting in itself. I was wanting to re-run all the merges with the new "git-merge-base -a" to see which merges might have had different merge bases, and you've actually done that. Interesting to see the numbers.

> * Is it worth it? That is, is the added complexity in the merge logic
>   worth the advantages of correctly handling some strange (but real
>   life) merge cases?

I am of two minds on this. I hate the notion of a more complex merge. But at the same time, it clearly is a very interesting case when we do have multiple possible shared parents, and I think that at the very least we should warn the user. And using a more complex merge algorithm when it happens seems to be a very valid thing to do.

Also, it's possible that other developers see more of the criss-crossing merges than I do - iow, they're probably more likely to happen in the throw-away trees than in some of the main trees. Neither of the two cases we've seen and had issues were merges I did, for example. Which means that your "1% of all merges" number is probably low. Of course, it's quite likely that in most cases, the "pick either one" approach will give the exact same result as the more complex merge.

Using python, which people have less exposure to, sounds like an additional thorny issue..

		Linus