Re: Bizarre missing changes (git bug?)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 21, 2008, 22:57 UTC
Message-ID: <alpine.LFD.1.10.0807211546590.3007@woody.linux-foundation.org>
In-Reply-To: <8C23FB54-A28E-4294-ABEA-A5766200768B@gmail.com>

[ git channel added back to cc, because this is an interesting question in 
  itself ]

On Mon, 21 Jul 2008, Tim Harper wrote:

Show 7 quoted lines

> 
> Another false impression I had is a merge conflict resolution would always be
> displayed in a merge commit.  However, after running over the merges again, if
> you pick the right or left, discarding the one or the other, nothing is shown
> in "git log -p" for the merge commit.  Is there a way to see what was chosen
> for a conflict resolution?  Seeing that in the merge commit would have made
> things a little more clear.

The default behavior for showing merges is "--cc", which is the condensed version that only shows _actual_ conflicts that got resolved differently from either of the sources.

But note how this is an "after-the-fact" determination: it doesn't look whether the merge _did_ conflict (because doing that would require re-running the whole merge!), but it looks whether the end _result_ is different from either side.

So you can easily have a merge that conflicts - but then you resolve that merge by picking just one side of the merge as the result. And in that case the "--cc" diff will not show anything at all - because the end result did not conflict with the sources of the merge!

So "--cc" only shows output if: the merge itself actually changed something from _all_ parents. This can happen if:

 - there was a non-trivial conflict, and the end result really was a 
   "mixture" of the two. The result wasn't just a select of either side, 
   it was a combination of the two.

   This is obviously one "common" case for a merge resolution.

   But it's equally common that when you merge something you just say "Ok, 
   that other side did it better, I'll just pick that version". And in 
   that case, "--cc" won't show anything at all, because it's not really a 
   conflict any more once you've done that choice.

 - There can also be an "evil merge" that actually adds/changes/deletes 
   code that didn't exist AT ALL in either side. And --cc is very much 
   designed to show that.

   This is actually not always a bad thing (despite the name "evil 
   merge"), because it happens regularly that one branch had changed some 
   infrastructure setup or other, and the other branch had added a totally 
   new use of that infrastructure - and as a result the _merge_ needs to 
   add that setup code that didn't exist in either of the branches (in one 
   because the use wasn't there, in the other because the setup wasn't 
   needed).

Anyway, this all means that yes, "--cc" _often_ shows conflicts, but not always - exactly because it doesn't show the ones that the merge had committed as a non-conflict.

If you actually want to see the _real_ conflicts that happened as the merge was done, you do have to re-do it.

		Linus