Re: The criss-cross merge case

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 27, 2005, 23:32 UTC
Message-ID: <Pine.LNX.4.21.0504271854240.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.44.0504271254120.4678-100000@wax.eds.org>

On Wed, 27 Apr 2005, Bram Cohen wrote:

Show 6 quoted lines

> The way Git handles this currently is very bad, because it forces the
> common ancestor to be from the same snapshot across all files, so this
> problem will happen if the modifications are made even in different files,
> not just different lines within the same file. That could be improved
> greatly by finding an LCA for each file individually, which is what
> Monotone does.

The git core is perfectly sufficient for getting all LCAs or per-file best LCAs; merge-base doesn't bother, currently, because the deficiencies of "merge" (a.k.a. diff3) are worse than the issues with chosing a suboptimal LCA.

My plan is to implement multi-file diff and merge with a suffix tree-based algorithm, and then revisit the history stuff once we have a merger that can do sensible things with this information.

Note that the present very bad merger is actually seems to be sufficient for the Linux kernel, where patches from different sides of a merge are generally either unrelated or are identical, and, otherwise, they tend to be true conflicts where people fixed the same bug independantly in different ways.

> Darcs, Codeville, and all the Arch descendants have better merge
> algorithms which don't have to pick a single common ancestor.

I've been looking at Darcs (which seems to have a good method, although I think the underlying diff isn't great), and Codeville still doesn't have any documentation. Arch's method is strictly weaker than 3-way merge, and generates more rejects (not even conflicts) in my experience than even CVS.

	-Daniel
*This .sig left intentionally blank*