Re: [PATCH] bring description of git diff --cc up to date

From: Jonathan Nieder <jrnieder@uchicago.edu>
Date: Jul 22, 2008, 16:19 UTC
Message-ID: <20080722111947.BIW29914@m4500-01.uchicago.edu>

Junio C Hamano wrote:

Show 11 quoted lines

> Jonathan Nieder <jrnieder@uchicago.edu> 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 :)