Re: Merge with git-pasky II.

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 14, 2005, 09:10 UTC
Message-ID: <Pine.LNX.4.58.0504140201130.7211@ppc970.osdl.org>
In-Reply-To: <7v64ypsqev.fsf@assigned-by-dhcp.cox.net>

On Thu, 14 Apr 2005, Junio C Hamano wrote:

Show 8 quoted lines

> 
> I have to handle the following cases.  I think I currently do
> wrong things to them:
> 
>   5.1a both head modify to the same thing.
>   5.1b one head removes, the other does not do anything.
>   5.1c both head remove.
>   5.3 one head removes, the other head modifies.

There's another interesting set of cases: one side creates a file, and the other one creates a directory.

> I am not sure what to do with 5.3.

My very _strong_ preference is to just inform the user about a merge that cannot be performed, and not let it be automated. BIG warning, with some way for the user to specify the end result.

The thing is, these are pretty rare cases. But in order to make people feel good about the _common_ case, it's important that they feel safe about the rare one.

Put another way: if git tells me when it can't do something (with some specificity), I can then fix the situation up and try again. I might curse a while, and maybe it ends up being so common that I might even automate it, but at least I'll be able to trust the end result.

In contrast, if git does something that _may_ be nonsensical, then I'll worry all the time, and not trust git. That's much worse than an occasional curse.

So the rule should be: only merge when it's "obviously the right thing". If it's not obvious, the merge should _not_ try to guess what the right thing is. It's much better to fail loudly.

(That's especially true early on. There may be cases that end up being obvious after some usage. But I'd rather find them by having git be too stupid, than find out the hard way that git lost some data because it thought it was ok to remove a file that had been modified)

			Linus