Re: git rebase: unexpected conflict

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 7, 2007, 20:22 UTC
Message-ID: <Pine.LNX.4.64.0702071214170.8424@woody.linux-foundation.org>
In-Reply-To: <7vr6t17ohb.fsf@assigned-by-dhcp.cox.net>

On Wed, 7 Feb 2007, Junio C Hamano wrote:

Show 5 quoted lines

> 
> That is because David Woodhouse has an evil merge at
> c45aa055c32b488fc3fd73c760df372b09acf69a.
> 
> Running "git show" on that commit would tell you the story.

It's not really "evil". It's just that our "--cc" strategy makes it look very odd. But if you then look at why it looks that odd, you can do:

	git diff 784f4d5..8dd851d drivers/mtd/nand/Kconfig

(those two sha1's are just the commits that got merged, as reported by "git show"), and you'll see what happened:

 - one branch added the MTD_NAND_CAFE entry
 - the other one had removed the MTD_NAND_AT91 entry
 - they were in the same location in the Kconfig file, so it was a real 
   data conflict
 - when David fixed it up, instead of just trivially selecting the config 
   entry that remained after the merge (MTD_NAND_CAFE), he *also* then 
   moved it to alphabetically the proper place in the file.

End result: doing a "git show" on the resulting commit does how something rather strange (the final result does indeed have lines that did not exist in *either* of the parents), but what it doesn't show is the cause of that strange thing, because that ended up being a non-conflict after the merge (ie remove the old entries from both files).

In general, the output of "--cc" for conflicting merges is really quite good, but it's can be a bit hard to read, and in cases like this, the "conflict" is shown in a way that doesn't exactly make the _original_ conflict obvious.

			Linus