All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Mike McGranahan <mike@mcgwiz.com>
Cc: git@vger.kernel.org
Subject: [PATCH] diff: move diff.wsErrorHighlight to "basic" config
Date: Fri, 31 Jan 2020 04:57:49 -0500	[thread overview]
Message-ID: <20200131095749.GB2916051@coredump.intra.peff.net> (raw)
In-Reply-To: <20200131091917.GC2857810@coredump.intra.peff.net>

On Fri, Jan 31, 2020 at 04:19:17AM -0500, Jeff King wrote:

> All that said, I kind of wonder if diff.wsErrorHighlight ought to be
> respected by even plumbing commands. After all, it does nothing unless
> color is enabled anyway, so I don't think it runs the risk of confusing
> a user of the plumbing. It's no different than color.diff.*, which we
> respect even in the plumbing commands (if the caller has manually asked
> for color, of course).

The more I pondered this, the more it seems like the right thing. So
here's a patch to do it.

I also suspect that some of the color-moved config would benefit from
the same treatment, but I haven't yet convinced myself. Unlike this
option, which impacts a single line, the move detection covers multiple
hunks, which you'd be picking out independently. Would that be weird, or
would it make sense as it's just annotating the existing diff?

-- >8 --
Subject: [PATCH] diff: move diff.wsErrorHighlight to "basic" config

We parse diff.wsErrorHighlight in git_diff_ui_config(), meaning that it
doesn't take effect for plumbing commands, only for porcelains like
git-diff itself. This is mildly annoying as it means scripts like
add--interactive, which produce a user-visible diff with color, don't
respect the option.

We could teach that script to parse the config and pass it along as
--ws-error-highlight to the diff plumbing. But there's a simpler
solution.

It should be reasonably safe for plumbing to respect this option, as it
only kicks in when color is otherwise enabled. And anybody parsing
colorized output must already deal with the fact that color.diff.* may
change the exact output they see; those options have been part of
git_diff_basic_config() since its inception in 9a1805a872 (add a "basic"
diff config callback, 2008-01-04).

So we can just move it to the "basic" config, which fixes
add--interactive, along with any other script in the same boat, with a
very low risk of hurting any plumbing users.

Signed-off-by: Jeff King <peff@peff.net>
---
 diff.c                     | 16 ++++++++--------
 t/t3701-add-interactive.sh | 13 +++++++++++++
 2 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/diff.c b/diff.c
index 8e2914c031..5e4471f15f 100644
--- a/diff.c
+++ b/diff.c
@@ -414,14 +414,6 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
 		return 0;
 	}
 
-	if (!strcmp(var, "diff.wserrorhighlight")) {
-		int val = parse_ws_error_highlight(value);
-		if (val < 0)
-			return -1;
-		ws_error_highlight_default = val;
-		return 0;
-	}
-
 	if (git_color_config(var, value, cb) < 0)
 		return -1;
 
@@ -450,6 +442,14 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
 		return color_parse(value, diff_colors[slot]);
 	}
 
+	if (!strcmp(var, "diff.wserrorhighlight")) {
+		int val = parse_ws_error_highlight(value);
+		if (val < 0)
+			return -1;
+		ws_error_highlight_default = val;
+		return 0;
+	}
+
 	/* like GNU diff's --suppress-blank-empty option  */
 	if (!strcmp(var, "diff.suppressblankempty") ||
 			/* for backwards compatibility */
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 2182b1c030..a28182c526 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -553,6 +553,19 @@ test_expect_success 'diffs can be colorized' '
 	grep "$(printf "\\033")" output
 '
 
+test_expect_success 'colorized diffs respect diff.wsErrorHighlight' '
+	git reset --hard &&
+
+	echo "old " >test &&
+	git add test &&
+	echo "new " >test &&
+
+	printf y >y &&
+	force_color git -c diff.wsErrorHighlight=all add -p >output.raw 2>&1 <y &&
+	test_decode_color <output.raw >output &&
+	grep "old<" output
+'
+
 test_expect_success 'diffFilter filters diff' '
 	git reset --hard &&
 
-- 
2.25.0.538.g1d5d7023b0


  reply	other threads:[~2020-01-31  9:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30 21:53 Patch text in git-add patch mode lacks whitespace highlighting Mike McGranahan
2020-01-31  9:19 ` Jeff King
2020-01-31  9:57   ` Jeff King [this message]
2020-02-01  0:48   ` Mike McGranahan
2020-01-31 12:37 ` Johannes Schindelin
2020-02-01  0:49   ` Mike McGranahan
2020-02-01 11:02   ` Jeff King
2020-02-01 21:06     ` Johannes Schindelin
2020-02-03  8:54       ` Jeff King
2020-02-03 12:37         ` Johannes Schindelin
2020-02-03 14:51           ` Jeff King
2020-02-04 18:29             ` Junio C Hamano
2020-02-04 19:57               ` Jeff King
2020-02-04 19:04             ` Johannes Schindelin

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=20200131095749.GB2916051@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=mike@mcgwiz.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.