public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Scott Baker <scott@perturb.org>
Subject: [PATCH] contrib/diff-highlight: do not highlight identical pairs
Date: Tue, 17 Mar 2026 19:02:23 -0400	[thread overview]
Message-ID: <20260317230223.GA716496@coredump.intra.peff.net> (raw)

We pair lines for highlighting based on their position in the hunk. So
we should never see two identical lines paired, like:

  -one
  -two
  +one
  +something else

which would pair -one/+one, because that implies that the diff could
easily be shrunk by turning line "one" into context.

But there is (at least) one exception: removing a newline at the end of
a file will produce a diff like:

  -foo
  +foo
  \No newline at end of file

And we will pair those two lines. As a result, we end up marking the
whole line, including the newline, as the shared prefix. And there's an
empty suffix.

The most obvious bug here is that when we try to print the highlighted
lines, we remove the trailing newline from the suffix, but do not bother
with the prefix (under the assumption that there had to be a difference
_somewhere_ in the line, and thus the prefix would not eat all the way
up to the newline). And so you get an extra line like:

  -foo

  +foo

  \No newline at end of file

This is obviously ugly, but also causes interactive.diffFilter to
(rightly) complain that the input and output do not match their lines
1-to-1.

This could easily be fixed by chomping the prefix, too, but I think the
problem is deeper. For one, I suspect some of the other logic gets
confused by forming an array with zero-indexed element "3" in a
3-element array. But more importantly, we try not to highlight whole
lines, as there's nothing interesting to show there. So let's catch this
early in is_pair_interesting() and bail to our usual passthrough
strategy.

Reported-by: Scott Baker <scott@perturb.org>
Signed-off-by: Jeff King <peff@peff.net>
---
It would perhaps make more sense for diff-highlight to chomp all
incoming lines, then do its comparisons, and then add a newline back on
output. That's a bigger change, so I punted on it for now.

 contrib/diff-highlight/DiffHighlight.pm          | 12 ++++++++++++
 contrib/diff-highlight/t/t9400-diff-highlight.sh | 11 +++++++++++
 2 files changed, 23 insertions(+)

diff --git a/contrib/diff-highlight/DiffHighlight.pm b/contrib/diff-highlight/DiffHighlight.pm
index 3d061bc0b7..f0607a4b68 100644
--- a/contrib/diff-highlight/DiffHighlight.pm
+++ b/contrib/diff-highlight/DiffHighlight.pm
@@ -273,6 +273,18 @@ sub highlight_line {
 # or suffix (disregarding boring bits like whitespace and colorization).
 sub is_pair_interesting {
 	my ($a, $pa, $sa, $b, $pb, $sb) = @_;
+
+	# We hit this case if the prefix consumed the entire line, meaning
+	# that two lines are identical. This generally shouldn't happen,
+	# since it implies the diff isn't minimal (you could shrink the hunk by
+	# making this a context line). But you can see it when the line
+	# content is the same, but the trailing newline is dropped, like:
+	#
+	#   -foo
+	#   +foo
+	#   \No newline at end of file
+	return 0 if $pa == @$a || $pb == @$b;
+
 	my $prefix_a = join('', @$a[0..($pa-1)]);
 	my $prefix_b = join('', @$b[0..($pb-1)]);
 	my $suffix_a = join('', @$a[($sa+1)..$#$a]);
diff --git a/contrib/diff-highlight/t/t9400-diff-highlight.sh b/contrib/diff-highlight/t/t9400-diff-highlight.sh
index dee296739c..2a9b68cf3b 100755
--- a/contrib/diff-highlight/t/t9400-diff-highlight.sh
+++ b/contrib/diff-highlight/t/t9400-diff-highlight.sh
@@ -340,4 +340,15 @@ test_expect_success 'diff-highlight handles --graph with leading dash' '
 	test_cmp expect actual
 '
 
+test_expect_success 'highlight diff that removes final newline' '
+	printf "content\n" >a &&
+	printf "content" >b &&
+	dh_test a b <<-\EOF
+	@@ -1 +1 @@
+	-content
+	+content
+	\ No newline at end of file
+	EOF
+'
+
 test_done
-- 
2.53.0.930.g4fb07a7d1b

                 reply	other threads:[~2026-03-17 23:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20260317230223.GA716496@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=scott@perturb.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox