[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-diffutils] bug#35214: bug#35214: [Bug][diff][3.3] diff showing diff
[bug-diffutils] bug#35214: bug#35214: [Bug][diff][3.3] diff showing difference when there is none
Wed, 10 Apr 2019 06:51:55 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
On 4/10/19 6:46 AM, Eric Blake wrote:
> On 4/9/19 11:03 PM, 方然 wrote:
>> [image: image.png]
>> it is a same line! and if I delete some lines above and below this line
>> then diff again it shows no difference as I expect.
>> and not only this line all these lines in the first screenshot are same
>> lines but show difference in diff.
>> also use vimdiff to check. and show no difference in vimdiff.
>> [image: image.png]
> Please don't ever send 9 megabytes of screenshots and sample files to a
> mailing list (actually, I was a bit surprised that your images were
> relatively small compared to the bulk of your log files, although it
> would still have been a better use of bandwidth to just paste the text
> from your window rather than capturing screenshots). You caused a lot of
> unnecessary load on the mail server as it multiplied your message out to
> every list recipient. Ideally, you should have minimized your problem
> down to much smaller files - although the nature of the reported problem
> in diff'ing large files may have indeed required the full log files to
> reproduce (where trimming things would have made the problem disappear);
> but even then, hosting your files externally and merely posting a URL in
> the mail is more considerate when you would otherwise be sending more
> than 100k to the list.
That said, when I use diff 3.6, I cannot reproduce the problem:
< 3 12 17
< 8 12 0
< 12 8 1
> 3 11 17
> 8 13 0
> 11 8 1
And the output that you reported, while annoying that it is not minimal,
is not _wrong_ per se (applying the diff still results in the correct
patched file, even if it required one line more effort than strictly
The NEWS file mentions for 4.4:
diff's default algorithm has been adjusted to output higher-quality
results at somewhat greater computational cost, as CPUs have gotten
faster since the algorithm was last tweaked in diffutils-2.6 (1993).
so it could have been those fixes that improved diff in the meantime.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature