Re: Handling merge conflicts a bit more gracefully..

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

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

> 
> Well, except that $I may validly be an empty tree ;-), so not
> quite.

Yeah, ok, so the fact that we allow missing things in the index (which was debatable to start with) makes for exceptions.

We could certainly be stricter about the index contents, and require that they match the branch we're merging from exactly, rather than be a subset. That said, I'm not convinced that it's worth it, even if it means that a two-way merge ends up acceping merges that a three-way one never would.

> In case it was not clear, where I am headed is this.  I would
> like to rip out the two-tree "carry forward" implementation from
> read-tree, and replace it with:

Yeah, I see that, I'm just not entirely convinced it's a good idea.

The thing is, a two-way merge really _is_ very different from a three-way one, in that it's a fast-forward, and the fact that it allows for things that the more complex "full" case wouldn't allow I feel is something of an advantage. And it _can_ allow them exactly because it's not the full case.

I like your concept:

Show 16 quoted lines

> When/if that happens, then the current fast-forward code would
> need to be changed from:
> 
>     read-tree -m $H $M && echo $M >.git/HEAD
> 
> to
> 
>     read-tree -m $H $M &&
>     if unmerged paths in the resulting cache
>     then
>         merge-cache -o merge-one-file-script -a
>     fi &&
>     echo $M >.git/HEAD
> 
> and the user's local changes since H when fast forwarding to M
> would be handled with the same workflow as the three-way case.

but that one doesn't really help the case of stuff he hasn't marked up-dated, so I think that's actually a special case that _isn't_ the important one. I think the case that is more important (and more likely to hit people) is when they have something in their working tree that conflicts with the merge, and then what you want is really that the current "update" code do the three-way merge in the working directory, not that it's done on the index file contents.

So I see where you are coming from, but I don't think the index file is the most important case. The more important case is the one that the three-way merge doesn't handle either!

		Linus