On 1/6/2011 4:04 PM, Jonathan Nieder wrote: > In case (1), -c will show a "combined diff" for files where master > does not match either the old master or topic. --cc, on the other > hand, will correctly suppress these uninteresting diffs. > > In case (2), -c will show a noisy "combined diff" as before. > --cc will show a combined diff when the changes from both parents > touch nearby code, even if it merged trivially. > > In case (3), -c and --cc will show the semantically boring but > syntactically interesting merge. > > Case (4) is underspecified. So let's give a more precise example: > the old master and topic tried to fix the same bug in two incompatible > ways. When merging, I decide I like the topic's way better, so I > resolve conflicts in favor of the topic. Hopefully all unrelated > changes on master were preserved! > > In this case, -c and --cc will very likely show nothing at all. > Each file matches one of the two parents (old master or topic) so > there is no easy way to distinguish the case from (0) or (1). That does help me understand the difference between -c and -cc, but I still don't see why one or the other is not the default behavior of log -p, instead of opting to never show anything at all for merges? -- 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