[Top][All Lists]

[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

From: Eric Blake
Subject: [bug-diffutils] bug#35214: bug#35214: [Bug][diff][3.3] diff showing difference when there is none
Date: Wed, 10 Apr 2019 06:51:55 -0500
User-agent: 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]