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

From: Eric Blake <[email-masked]>
Date: Mon, 08 Dec 2014 17:04:55 -0700

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