diff options
author | Jeff King <peff@peff.net> | 2014-05-12 14:39:55 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-05-12 11:44:22 -0700 |
commit | 0f20ae29889d61f2e93ae00fd34f1cdb53285702 (patch) | |
tree | 21516c632031aeb1435698c438fd085e18ec0faf | |
parent | c9870837feaa5d9b50cd19c7b87dd50778cb4f41 (diff) | |
download | git-ab/add-interactive-show-diff-func-name.tar.gz |
SQUASH??? git-add--interactive: Preserve diff heading when splitting hunksab/add-interactive-show-diff-func-name
This makes a lot of sense to me. I did notice two interesting quirks,
one of which might be worth addressing.
One, there is a slightly funny artifact in that the hunk header comes
from the top of the context line, and that top is a different position
for each of the split hunks. So in a file like:
header_A
content
header_B
one
two
three
four
you might have a diff like:
@@ ... @@ header_A
header_B
one
two
+ new line 1
three
+ new line 2
four
The hunk header for "new line 1" is "A", because "B" itself is part of
the context. But the hunk header for "new line 2", if it were an
independent hunk, would be "B". We print "A" because we copy it from the
original hunk.
It probably won't matter much in practice (and I can even see an
argument that "A" is the "right" answer). And figuring out "B" here
would be prohibitively difficult, I would think, as it would require
applying the funcname rules internal to git-diff to a hunk that git-diff
itself never actually sees.
Since the output from your patch is strictly better than what we saw
before, I think there is no reason we cannot leave such an improvement
to later (or never).
> The diff is somewhat larger than I initially expected because in order
> to display the headings in the same color scheme as the output from
> git-diff(1) itself I had to split up the code that would previously
> color diff output that previously consisted entirely of the fraginfo,
> but now consists of the fraginfo and the diff heading (the latter of
> which isn't colored).
The func heading is not colored by default, but you can configure it to
be so with color.diff.func. I double-checked the behavior with your
patch: you end up with the uncolored header in the split hunks, because
it is parsed from the uncolored line. Which is not bad, but I think we
can trivially do better, just by adding back in the color as we do with
the fraginfo.
-rwxr-xr-x | git-add--interactive.perl | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/git-add--interactive.perl b/git-add--interactive.perl index 5bc3e9ea05..4158f727c4 100755 --- a/git-add--interactive.perl +++ b/git-add--interactive.perl @@ -29,6 +29,10 @@ my ($fraginfo_color) = $diff_use_color ? ( $repo->get_color('color.diff.frag', 'cyan'), ) : (); +my ($funcname_color) = + $diff_use_color ? ( + $repo->get_color('color.diff.func', ''), + ) : (); my ($diff_plain_color) = $diff_use_color ? ( $repo->get_color('color.diff.plain', ''), @@ -899,7 +903,7 @@ sub split_hunk { unshift @{$hunk->{DISPLAY}}, join( "", $diff_use_color ? colored($fraginfo_color, $fraginfo) : $fraginfo, - $heading, + $diff_use_color ? colored($funcname_color, $heading) : $heading, "\n" ); } |