Re: Confused about diff-tree --cc output

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> Is that about right?

Yes, not just about right but it is how it works.

The patch in:

    http://article.gmane.org/gmane.comp.version-control.git/15500

gave the final implementation of the rule.

The rule is that if there are only one or two variations to choose from,
and the result matches one of them, it is not interesting.  Otherwise it
is interesting.

In an octopus where more than two parents disagree, no matter what the
result is, it is interesting.

In an extreme case, even if both parents in a two-parent merge had the
same contents (i.e. only one to choose from), if you amend the merge
result to make it different from it, it becomes interesting.

In your example, two pieces, each of which took everything from one parent
(hence is uninteresting by itself), happened to lie within the context
range.  It is not very interesting, and it automerges cleanly, but it is
rare that these merges happen close together, and that "close miss" is
what makes this case "interesting".

It is exactly the same as the example in the message I referred you to.
In the same thread:

    http://article.gmane.org/gmane.comp.version-control.git/15598

has a very clear explanation about this exact kind of borderline "is it
really interesting?" case.

Also the follow-up to it:

    http://article.gmane.org/gmane.comp.version-control.git/15600

would give you further insights, the most interesting of which is that
what is shown in --cc output does *NOT* have anything to do with "did the
merge result in a manual conflict resolution?"

By the way, the latter message talks about gitk not showing the right
thing, but that was an ancient story.  These days gitk just shows what
diff --cc feeds it and there is no discrepancy between the two.