Re: incorrect range-diff output?

[Thomas Gummerer <t.gummerer@gmail.com>]

On 04/13, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
> 
> > I'm not sure what the right solution for this is.  I think one thing
> > I'd like range-diff to do is to add the filename, or some context
> > (e.g. is this part of the commit message etc.) to the @@ line (not
> > sure what that is called?).
> 
> Perhaps the inner diff can be done with the usual funcname/xfuncname
> logic so that the real function name of the payload is on the @@
> lines (they are internally called "hunk header" lines, I think).

The inner diff is actually currently done this way, however we then
strip out the funcname.  My understanding is that that is mostly done
to get rid of the line numbers which can change between ranges, so I'm
re-introducing that, while only stripping the actual line numbers
out.

I do feel like the filenames should probably have priority in the
outer diffs hunk header lines though, as we can only add a limited
amount of information there, and without the filename, the function
name might be less useful (or it may be not useful at all, for things
where we don't have proper funcnames, e.g. for documentation).

> And then the outer diff (i.e. the one that compares two inner diff
> output) can use a special funcname pattern that says "treat the
> lines that begin with '@@ ' as the function name line", instead of
> (or in addition to??) the logic that says "lines that begin with
> 'diff --git' have interesting information" which led to a misleading
> piece of information in the range-diff output under discussion,
> perhaps?

I don't think there ever was a logic that says "lines that begin with
'diff --git' have interesting information", but rather that's how the
range-diff was interpreted, because there was no indication that those
lines don't have interesting information.

My series implements something very similar to  what you're describing
though, except I'm introducing a new type of header for the filename,
as I think that's more important, as mentioned above.