Re: Confused about diff-tree --cc output

Jay Soffian <jaysoffian@gmail.com> writes:

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.