mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Thomas Gummerer <>
To: Junio C Hamano <>
Cc: Duy Nguyen <>,,
	Johannes Schindelin <>
Subject: Re: incorrect range-diff output?
Date: Sun, 14 Apr 2019 22:20:56 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 04/13, Junio C Hamano wrote:
> Thomas Gummerer <> 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

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.

  reply	other threads:[~2019-04-14 21:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 11:17 incorrect range-diff output? Duy Nguyen
2019-04-11 22:05 ` Thomas Gummerer
2019-04-12  8:41   ` Johannes Schindelin
2019-04-14 21:12     ` Thomas Gummerer
2019-04-12  9:21   ` Duy Nguyen
2019-04-12 15:02   ` Junio C Hamano
2019-04-14 21:20     ` Thomas Gummerer [this message]
2019-04-15  2:01       ` Junio C Hamano
2019-04-15 12:40     ` Johannes Schindelin
2019-04-14 21:09   ` [RFC PATCH 0/4] output improvements for git range-diff Thomas Gummerer
2019-04-14 21:09     ` [RFC PATCH 1/4] range-diff: fix function parameter indentation Thomas Gummerer
2019-04-14 21:09     ` [RFC PATCH 2/4] range-diff: don't remove funcname from inner diff Thomas Gummerer
2019-04-14 23:21       ` Eric Sunshine
2019-04-15 12:54         ` Johannes Schindelin
2019-04-15 18:56           ` Thomas Gummerer
2019-04-17 11:52             ` Johannes Schindelin
2019-04-24 18:15               ` Thomas Gummerer
2019-04-15 12:53       ` Johannes Schindelin
2019-04-15 18:57         ` Thomas Gummerer
2019-04-14 21:09     ` [RFC PATCH 3/4] range-diff: add section header instead of diff header Thomas Gummerer
2019-04-14 23:29       ` Eric Sunshine
2019-04-15  6:28         ` Johannes Sixt
2019-04-15 13:01         ` Johannes Schindelin
2019-04-15 19:09           ` Thomas Gummerer
2019-04-14 21:09     ` [RFC PATCH 4/4] range-diff: add section headers to the outer hunk header Thomas Gummerer
2019-04-15 12:44       ` Johannes Schindelin
2019-04-15 18:48         ` Thomas Gummerer
2019-04-15 12:47     ` [RFC PATCH 0/4] output improvements for git range-diff Johannes Schindelin
2019-04-15 19:25       ` Thomas Gummerer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).