Junio C Hamano <gitster@xxxxxxxxx> writes:
> Jonathan Nieder <jrnieder@xxxxxxxxxxxx> writes:
>
>> Just to make sure I understand, here is what I think --cc does:
>>
>> - In a two-parent merge, it is exactly as Linus has been
>> ...
>> - In a many-parent merge, the criterion is more stringent.
>> ...
>>
>> Is that correct?
>
> The logic in the code does not have separate criteria for two-parent and
> Octopus cases. Actually Linus talks about "when you have two versions to
> choose from, and if the result matches one of them, then it is not
> interesting". In a two-parent merge, you cannot have three or more
> possible versions to choose from by definition, can you?
To put it another way, I think what you wrote is correct, but two-parent
case is just a degenerated case of a more general rule, that is:
A hunk is not interesting if the person who merged had only two
choices offered by the parents to pick from, and the merge result
exactly matched one of the choices.
You can come up with examples that do not match the above criteria; they
are all interesting.
For example, if all the parent of a tripus disagreed, the person had more
than two choices to pick from, so no matter what the resolution is, the
hunk is interesting.
On the other hand, if 4 parents in a dodecapus lack a line that all other
8 parents have (see the first example in [*1*]), then the choice for the
person who merges these 12 parents is either to include or not include
that line. If the line was included, it is not interesting. If the line
was deleted (which is different from what happened in *1*), it is not
interesting, either.
One thing to note is "have only two choices to pick from" does not have a
direct connection to two-parent-ness. In a two-parent merge (di-pus?), by
definition you cannot have more than two choices, but that is not any
different from a Dodecapus that has only two groups of parents. Most
octopus merges have only two groups of parents like the "merge from hell"
does when we talk about individual paths (otherwise it would be very
painful to resolve so it is not done in practice).
[Reference]
*1* http://article.gmane.org/gmane.comp.version-control.git/15487
--
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
