[ git channel added back to cc, because this is an interesting question in itself ] On Mon, 21 Jul 2008, Tim Harper wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
