Re: Handling merge conflicts a bit more gracefully..

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 9, 2005, 04:54 UTC
Message-ID: <Pine.LNX.4.58.0506082145160.2286@ppc970.osdl.org>
In-Reply-To: <7vfyvsuoz3.fsf@assigned-by-dhcp.cox.net>

On Wed, 8 Jun 2005, Junio C Hamano wrote:

Show 9 quoted lines

> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
> 
> LT> Yeah, ok, so the fact that we allow missing things in the
> LT> index (which was debatable to start with) makes for
> LT> exceptions.
> 
> Not just that.  Another big difference is that we allow _extra_
> things in the index in two-tree case (i.e. local additions).
> But I do not think these exceptions are necessarily bad.

Well, they'd be bad in a three-way merge.

The reason they aren't bad in a two-way merge is that you don't commit the result - the commits have been done already.

That's really the big conceptual difference between two-way and three-way: never mind the merge algorithm itself.

(In fact, in many ways, two-way merges are really just the same as a one-way merge, except it now knows where it came from, so it can do sanity checking).

As to working tree changes:

Show 5 quoted lines

> which means we are exactly in the same situation as "merge I and
> M pivoting on H" three-way merge, with a dirty work tree.  Any
> solution and help we would give to the end-user for the
> three-way case would automatically help this two-way case,
> wouldn't it?

Yes.

In fact, there's a fairly simple solution, which is to remove the current check for "verify_uptodate()" and instead replace it with the "update" phase not just writing the file, but actually doing a three-way merge on it.

NOTE! This would not affect the resulting _tree_ in any way at all. It would literally only affect how we write out the working directory. Right now we just fail when the working file isn't up-to-date, and that could be replaced with instead doing a

	merge W I M

where "W" is the working file, "I" is the index file, and "M" is the merge result that we currently just write out directly.

In the special case of I == M, we already do _exactly_ this: we know that since I=M, the merge will be W, so we don't do the update at all.

So in fact, doing a 3-way merge is really a generalization of what we already do, and removes a failure case.

NOTE! This 3way merge is fundamentally _different_ from the 3-way merge that is done by "git-merge-one-file-script" that we already do. _That_ 3-way merge is done not on the working files, but on the results in the trees, while this new 3way merge would be done purely in the working directory (ie it wouldn't make sense without the "-u" flag).

If we do this, I'd personally suggest it be another flag, possibly "-u3" instead of just plain "-u".

		Linus