Re: SEGV in git-merge recursive:

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 31, 2007, 00:35 UTC
Message-ID: <Pine.LNX.4.64.0703301728510.6730@woody.linux-foundation.org>
In-Reply-To: <Pine.LNX.4.63.0703302239050.4045@wbgn013.biozentrum.uni-wuerzburg.de>

On Fri, 30 Mar 2007, Johannes Schindelin wrote:

Show 5 quoted lines

> 
> IMHO, there is actually no way merge_trees() can fix the conflicts enough 
> to write a tree.
> 
> So, the only way I see to avoid that SEGV is to something like this:

I disagree.

It's much better to give a bad intermediate tree than to give up entirely.

If you give up entirely, the merge is basically impossible to complete.

If you give a bad intermediate, the merge will just have potentially more-than-necessary conflicts in the end.

> +			die ("cannot continue merging.");

This really isn't acceptable. We're not monotone or one of those projects that thinks that merging is hard. Merging is *easy*.

We're looking for a base version for a merge - think of a three-way merge on a file level. And the easiest base version is actually an empty base file (or, when it comes to a rename conflict, no base names at all).

Sure, that will make all changes conflict, but that's a *hell* of a lot better than giving up. It just means that now the user has to figure out what the end result should be - exactly the same way that if you have an empty file as a base version, a three-way merge will basically generate a conflict marker that looks like

	<<<<
	one version of the file
	====
	the other version of the file
	>>>>

Rule #1 when merging should *always* be: "never leave the user high and dry". You don't give up and say "I can't merge this". You say "I couldn't merge this, but here's the mess I left for you to show me how it's done!"

		Linus