Re: incorrect range-diff output?

From: Thomas Gummerer <t.gummerer@gmail.com>
Date: Apr 14, 2019, 21:20 UTC
Message-ID: <20190414212056.GI32487@hank.intra.tgummerer.com>
In-Reply-To: <xmqqo95bxo4p.fsf@gitster-ct.c.googlers.com>

On 04/13, Junio C Hamano wrote:

Show 10 quoted lines

> 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).

Show 7 quoted lines

> 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.