Re: unified diff bug or intended behaviour?

[Tom Rodriguez]

I agree that it's not clear cut but it's not quite right for my 
purposes so I though I'd point it out.  The notion of differences 
becomes very fuzzy once you start to ignore things, especially in the 
unified format.  I had a specific purpose in mind so of course the 
answer I wanted seemed clear to me.  ;)  I'm my case I'm using the 
unified diff format to produce change summaries for use by a code 
reviewer, so representing the final form of the code is a little more 
important than the old form.  Also I provide other views that can 
makes this clearer if the unified form is confusing.  In most cases 
the unified form provides a very clear, compact representation of 
edits.  Extremely complicated edits don't parse well in any diff 
format  I'm probably going to solve my problem by directly parsing 
context diffs into a unified form, which I think ends up actually 
being better for me.

It might be nice if GNU diff had an option to select the file1 
unchanged context instead of file0 though that seems like feature 
creep.  I do like the --*-format= options as a way of providing 
configurable diff output, though it appears to me they don't seem to 
affect the unified diff format.  Maybe extending the generalized 
formatting to the unified form would be sufficient and more general.

Anyway, thanks for your time.

tom

Paul Eggert wrote:
> Tom Rodriguez <address@hidden> writes:
>
>
> > This would be easy to fix by changing pr_unidiff_hunk to print from
> > files[1] instead of files[0] for the unchanged part.  Thanks!
>
>
> That would fix that particular case, but then it will break the
> apparent indentation when looking at hunks that contain "old" lines
> (i.e., lines from files[0]).  I don't see an easy fix here.