On Fri, 30 Mar 2007, Johannes Schindelin wrote:
>
> 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
-
To unsubscribe from this list: 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