Re: CVS/Diff merge defect. (fwd)

[Paul Eggert]

This message follows up on an old Diff bug report by Kevin Pearson

and proposed patch by Karl Tomlinson
.

> Date: Tue, 15 Aug 2000 16:33:50 +1200
> From: Karl Tomlinson <[EMAIL PROTECTED]>
> 
> I include patches for version 2.7 of diffutils to use OLDFILE as the
> common file when a merge or edscript is requested of diff3.  I think the
> --inhibit-hunk-merge option of 2.7.2 is no longer required.

Thanks for the analysis and patch.  I fixed the problem in a somewhat
different way, and you can see the result in the latest test version
of GNU diffutils, in:

ftp://alpha.gnu.org/gnu/diffutils/diffutils-2.7.10.tar.gz

(The fix has actually been present since diffutils test version 2.7.3
 in November, but I forgot to drop you a line then.)

> I can submit patches for cvs also but I'll wait to see if there is
> feedback on this.

Sorry about the late feedback, and thanks again for the fix.  (Also
thanks to Jim Meyering who kept bugging me to release a fixed version
of diffutils.  :-)

___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs

Re: CVS/Diff merge defect. (fwd)

[Karl Tomlinson]

From: Paul Eggert 
Subject: Re: CVS/Diff merge defect. (fwd) 
Date: Fri, 30 Jun 2000 10:01:18 -0700 

I think you may be onto a bug here (even with diffutils 2.7.2), but
I
couldn't reproduce the problem with these test cases.  Your patch to
diffutils 2.7 made no difference in the output of the first command.
For the second command, you didn't supply testcase1-1.2 or
testcase0-1.1.2.1 in your message, so I created them with:

co -p1.2 testcase1 >testcase1-1.2
co -p1.1.2.1 testcase0 >testcase0-1.1.2.1

After doing this, I found no difference in executing the second
command between diffutils 2.7, 2.7 with your fix, and 2.7.2.

The second command seemed a bit odd, as I would have expected the
last
file to be testcase1-1.1.2.1 instead of testcase0-1.1.2.1.  So I
also
tried running "diff3 -E -am testcase1 testcase1-1.2
testcase1-1.1.2.1"
but also got the same results with all three versions of diff.

So I must be doing something wrong in trying to reproduce the bug.
Can you help me out in trying to reproduce it, with diffutils only?
Thanks.

I don't know why testcase0 is giving the same results with all versions
of diff as I get different results with 2.7 and 2.7.2, and I think 2.7
gives the better answer.

For testcase1, I think the appropriate command should be
`diff3 -E -am testcase1 testcase1-1.1 testcase1-1.1.2.1'.
I also get different results with 2.7 and 2.7.2, but I think 2.7.2 gives
the better answer.

Note that
`cat testcase0-1.1.2.2 | diff3 -E -am testcase0 testcase0-1.1 -'
gives the correct answer with either version of diff, as does
`cat testcase1-1.1.2.1 | diff3 -E -am testcase1 testcase1-1.1 -'

The better answers when YOURFILE is STDIN are due to OLDFILE (instead of
YOURFILE) being the common file in the two diffs that are run.  When
MYFILE is compared to OLDFILE it gives a better indication of the
intended changes to the file.  The file was not changed from YOURFILE to
MYFILE so a diff between these two files has little information about
what the intended changes were.  See also comments in the patch
supplied.

Does anyone know if there was a reason why YOURFILE was used as the
common file for the two diffs?  Ediff for emacs uses OLDFILE as the
common file and has always worked well for me.

I have another example attached which gives the same (incorrect) answers
to 
`diff3 -E -am test2-mine test2-older test2-yours' (test2-merged-2.7)
with either version of diffutils, but the same (correct) answers to
`cat test2-older | diff3 -E -am test2-mine test2-older -'
(test2-merged-2.7-stdin).

I include patches for version 2.7 of diffutils to use OLDFILE as the
common file when a merge or edscript is requested of diff3.  I think the
--inhibit-hunk-merge option of 2.7.2 is no longer required.

I can submit patches for cvs also but I'll wait to see if there is
feedback on this.

Thanks for your investigation.
 diff-bug.tar.gz

Re: CVS/Diff merge defect. (fwd)

[Paul Eggert]

   Date: Thu, 15 Jun 2000 13:52:29 -0600 (MDT)
   From: Kevin Pearson <[EMAIL PROTECTED]>

   This seemed to be related to the problem that was discovered by Noah
   Friedman <[EMAIL PROTECTED]> and patched by Paul Eggert
   <[EMAIL PROTECTED]> back in November of 1996.  Paul's patch he
   in-effect turned off shift_boundaries (which optimizes the diff by
   merging hunks if possible.)  This fixed the problem described by Noah.

As I mentioned in that message, that patch was a quick hack.  What I
hope is a better fix can be found in the latest test version of diffutils, at:
ftp://alpha.gnu.org/gnu/diffutils/diffutils-2.7.2.tar.gz
It adds a new option inhibit_hunk_merge which turns off hunk merging,
which is causing most of the problem.

Even this better fix is not ideal, because what we want is a true
3-way diff, that can inspect all three input files simultaneously and
minimize the resulting output.  But that's a long story.

   To test diff3, run the the command:
 diff3 -E -am testcase0 testcase0-1.1 testcase0-1.1.2.2
   and
 diff3 -E -am testcase1 testcase1-1.2 testcase0-1.1.2.1

I think you may be onto a bug here (even with diffutils 2.7.2), but I
couldn't reproduce the problem with these test cases.  Your patch to
diffutils 2.7 made no difference in the output of the first command.
For the second command, you didn't supply testcase1-1.2 or
testcase0-1.1.2.1 in your message, so I created them with:

co -p1.2 testcase1 >testcase1-1.2
co -p1.1.2.1 testcase0 >testcase0-1.1.2.1

After doing this, I found no difference in executing the second
command between diffutils 2.7, 2.7 with your fix, and 2.7.2.

The second command seemed a bit odd, as I would have expected the last
file to be testcase1-1.1.2.1 instead of testcase0-1.1.2.1.  So I also
tried running "diff3 -E -am testcase1 testcase1-1.2 testcase1-1.1.2.1"
but also got the same results with all three versions of diff.

So I must be doing something wrong in trying to reproduce the bug.
Can you help me out in trying to reproduce it, with diffutils only?
Thanks.