Re: Comments on recursive merge..

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 7, 2005, 16:56 UTC
Message-ID: <Pine.LNX.4.64.0511070848440.3193@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0511070837530.3193@g5.osdl.org>

On Mon, 7 Nov 2005, Linus Torvalds wrote:

Show 6 quoted lines

> 
>   I just hit my first real rename conflict, and very timidly tried the 
> "recursive" strategy in the hopes that I wouldn't need to do things by 
> hand.
> 
> It resolved things beautifully. Good job.

Btw, one thing that it does is print out too much information.

In particular, I had renames on both sides of the merge (in case anybody wants to see which one I'm talking about: it's the current top-of-head commit in the kernel archives: 333c47c847c90aaefde8b593054d9344106333b5).

Now, renames that you've done yourself you really don't want to hear about, at least if the other side didn't change anything in that file.

Renames that the _other_ side has done (the one you're merging) you may or may not want to know about, regardless of whether they happened to files that are changed. But since "git pull" will do a "git-apply --stat" at the end and show the renames there, I'd argue that the merge strategy itself should be quiet about any renames that are trivial.

So how about talking about renames only if you end up also doing a file-level merge? As it is, doing the merge talked about renames that I had merged earlier in my own branch, which is just confusing.

		Linus