Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxxxxx> writes:
>
>> + This flag implies the '-c' option and makes the patch output
>> + even more compact by omitting uninteresting hunks. A hunk is
>> + considered interesting only if either (a) it shows changes from
>> + all parents or (b) in an Octopus merge, it shows different changes
>> + from at least three different parents.
>
> I am not sure where that "at lesta three different parents" comes from.
> It might be that what the logic does can be expressed that way, but that
> was not the guiding principle why the code does what it currently does.
Yes, exactly - this is what I meant in saying "my proposed text
does not suggest very strongly what --cc is intended to do". I
haven't found any wording yet that both makes it clear what --cc
actually does and follows a thought process suggesting why.
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
describing it. A hunk is interesting if and only if
it shows changes from both parents.
- In a many-parent merge, the criterion is more stringent.
As in the two-parent merge case, the hunk must show no
changes from at least one of the parents, meaning that
one of several alternatives for that portion of code
was chosen by the code integrator (without mixing and
matching or adding additional changes); but further, there
must have been only two alternatives for that portion of
code to choose between. If there were three distinct
alternatives, no matter what the code integrator does, the
hunk will show up (because that is so rare and deserves
attention).
Is that correct?
Thanks for the reading matter. If it stimulates anyone reading
into coming up with a better description, they should please let
me know :)
--
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
