Re: misleading diff-hunk header

Tim Chase [off-list ref] writes:

On 08/21/12 10:22, Thomas Rast wrote:

quoted

Tim Chase [off-list ref] writes:

quoted

diff.{type}.xfuncname seems to start searching backwards in
from the beginning of the hunk, not the first differing line.

[...]

quoted

  @@ -4,4 +4,5 @@ int call_me(int maybe)

   int main()
   {
  +  return 0;
   }

misleadingly suggesting that the change occurred in the call_me()
function, rather than in main()

I think that's intentional, and matches what 'diff -p' does.  It gives
you the context before the hunk.  After all, if a new function starts in
the leading context lines, you can see that in the usual diff data.

Correct.  It is about "give the user _more_ hint/clue on the context
of the hunk", in addition to what the user can see in the
pre-context of the hunk, so it is pointless to hoist "int main()"
there.

...  It just makes it hard for me to gather some stats on the
functions that changed, and requires that I look in more than one
place (both in the header, and in the leading context) rather than
having a single authoritative place to grep.

The right way to answer "which functions were touched?" question is
to ignore what you see on the hunk header "@@ .. @@" lines and only
look at the patch text, running "git diff" with larger number of
context lines as necessary.

If you have a large patch hunk that adds or removes two or more new
functions, you would have to look at the patch text _anyway_ to
learn about these two or more names---they cannot possibly both
appear on the hunk header lines, so looking at the context hint
there is pointless for the purpose for which you are using "diff"
output.