bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19319: ? Unexpected behavior in diff(1)


From: Eric Blake
Subject: bug#19319: ? Unexpected behavior in diff(1)
Date: Mon, 08 Dec 2014 17:04:55 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 12/08/2014 04:50 PM, Todd Shandelman wrote:

[please don't top-post on technical lists]

> Thanks.
> Well, I must say that is all rather counter-intuitive.
> I never dreamed that the amount of context I select would actually affect
> the diff itself and how it is computed.

The diff is computed the same way.  All that --ignore-matching-lines
changes is how the result is output, after the diff is already computed.
 If you think the algorithm should be changed, that is a matter for the
diffutils mailing list; coreutils does not maintain diff(1), so
complaining here won't change it (other than the tangential fact that
many of the same developers hang out on both lists).

On the other hand, there ARE cases where different diff algorithms can
pick entirely different lines in a diff, but where both output forms are
valid patches.  If you are familiar with git, compare the Myers (greedy)
vs. minimal vs. patience algorithms - they can produce DRASTICALLY
different line counts and even hunk counts in the number of lines
diff'd.  If diff(1) were to learn multiple algorithms, the way git
already has, then maybe it would be worth tweaking one or more of those
algorithms to ignore input lines that match a regex prior to coming up
with the final computed diff for output - but it's not necessarily going
to be a trivial task to do that and still keep the diff'ing algorithm fast.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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