git-diff-tree --cc on the dodecapus

git-diff-tree --cc on the dodecapus

[Paul Mackerras]

Junio,

When I use git diff-tree --cc on Len's dodecapus merge (9fdb62af), the
first diff hunk that it shows is this:

@@@@@@@@@@@@@ -712,17 -711,9 -703,9 -703,9 -703,9 -708,9 -703,9 -703,9 -711,9 -703,9 -711,9 -711,9 +717,17 @@@@@@@@@@@@@
            	load_ramdisk=	[RAM] List of ramdisks to load from floppy
            			See Documentation/ramdisk.txt.
            
 -----------	lockd.udpport=	[NFS]
 +++++++++++	lockd.nlm_grace_period=P  [NFS] Assign grace period.
 +++++++++++			Format: <integer>
 +++++++++++
 +++++++++++	lockd.nlm_tcpport=N	[NFS] Assign TCP port.
 +++++++++++			Format: <integer>
 ++++ ++++++
     -      	lockd.tcpport=	[NFS]
 +++++++++++	lockd.nlm_timeout=T	[NFS] Assign timeout value.
 +++++++++++			Format: <integer>
     +      
 ---- ------	lockd.tcpport=	[NFS]
 +++++++++++	lockd.nlm_udpport=M	[NFS] Assign UDP port.
 +++++++++++			Format: <integer>
            
            	logibm.irq=	[HW,MOUSE] Logitech Bus Mouse Driver
            			Format: <irq>

For some reason, the 6th parent's lines are getting matched
differently from the other parents.  Parents 2-12 are actually all the
same in this file AFAICS.  All that has happened is that a sequence of
three lines: "lockd.udpport=  [NFS]", a blank line, "lockd.tcpport=
[NFS]", have been replaced by 11 lines.  For parent 6, the blank line
has been matched with the 6th line of the new stuff, whereas for
parents 2..5 and 7..12 the blank line has been matched with line 9 of
the new stuff.  This makes it look like the change from parent 6 is
different when it isn't really, and thus the diff looks interesting
when it shouldn't.

In general, I have found in doing N-way diff displays (both in dirdiff
and in gitk), that one needs to be a bit clever about working out
which lines correspond in the N versions.  If you do a series of 2-way
diffs and just believe what diff tells you about which lines
correspond, you will end up with things being shown as different when
they aren't.  Where there is ambiguity, some of the 2-way diffs will
resolve it one way and some another, and as a result, something which
is in fact common to all the files can end up being shown as a
difference.

What I do in dirdiff is to do a number of 2-way diffs, but just use
the result as an indication of which parts of the files have some
difference.  I then find the matches between all the files in Tcl code
and work out which lines are common and which lines are unique.  I
have found it necessary to apply a rule that says that a match across
a larger number of files is preferable to a match across a smaller
number, even if it is a longer match.  For a set of lines, I
iteratively pull out the best match (most number of files, then most
number of lines).  What's left at the end is the lines that are unique
to one file.  This ends up being a bit complicated, but it seems to be
necessary for producing a reasonable result.  I can go into more
detail on the algorithm I use if you want.

Paul.

Re: git-diff-tree --cc on the dodecapus

[Junio C Hamano]

Paul Mackerras <paulus@samba.org> writes:

> Junio,
>
> When I use git diff-tree --cc on Len's dodecapus merge (9fdb62af), the
> first diff hunk that it shows is this:

Yeah, I noticed it too, and you described how that happens quite
well.  The algorithm is simplistic and improvement patches are
welcome.