Re: needs merge

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 10, 2006, 05:21 UTC
Message-ID: <Pine.LNX.4.64.0601092356400.25300@iabervon.org>
In-Reply-To: <7vy81reoie.fsf@assigned-by-dhcp.cox.net>

On Sat, 7 Jan 2006, Junio C Hamano wrote:

Show 6 quoted lines

> *1* While I was trying out the above scenario, I noticed that
> resolve strategy does not notice this and ended up picking one
> ancestor at random.  I think this is because case #16 covers
> only the case where the path P is not changed between C and E
> and D and F, and case #11 must pick an ancestor and picks one at
> random.  Daniel, any thoughts on this?

Right; in this case, we really want to use a merge program that takes multiple ancestors and handles the equivalent to case #16 at the hunk level, but we don't have such a program available. Such a program would be able to identify whether case #16 ever actually occurs for a hunk, which is important because there will generally be a bunch of case #11s at the file level, even if there aren't any reverts (if the common ancestors disagreed before, and the two branches both changed the file to something entirely new, with no reverts, either ancestor is correct to use and the merge result will be useful; we only need to be careful if there were reverts somewhere, which leads to the possibility of false sharing between a branch and an ancestor, and thereby to ignoring the revert, and my feeling is that rejecting case #11 with divergant ancestors would lead to too many conflicts to make crossing merges useable).

One possibility, actually, is to steal a trick from the recursive strategy, and have a multi-ancestor merge program which merges all of the ancestors with a merge-style diff (i.e., merge output, but on diff instead of diff3, with all differences being conflicts), and then uses the result as the ancestor for the three-way merge. It seems to me that this would capture the central advantage of the recursive strategy without quite so much work. Or I might be completely wrong; I'm kind of worn out, and may not be thinking clearly.

	-Daniel
*This .sig left intentionally blank*