From: Jeff King <peff@peff.net>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: ["BUG"] builtin add-interactive does not honor 'color.diff. frag'
Date: Fri, 6 Nov 2020 12:03:45 -0500 [thread overview]
Message-ID: <20201106170345.GA174555@coredump.intra.peff.net> (raw)
In-Reply-To: <313B8999-1E99-4695-A20D-E48840C30879@gmail.com>
On Fri, Nov 06, 2020 at 11:31:32AM -0500, Philippe Blain wrote:
> I tried the builtin add-interactive for the first time today,
> and noticed a very minor difference with the Perl version.
> The title says it all.
>
> Repro:
>
> # Change the default color
> $ git config color.diff.frag "magenta bold"
> # Compare
> $ git add -p
> # and
> $ git -c add.interactive.useBuiltin=true add -p
> # I'm on latest master
> $ git --version
> git version 2.29.2.154.g7f7ebe054a
It looks like the code in add-interactive.c uses "fraginfo" instead of
"frag". But there's something much more puzzling, which is that it
checks color.interactive.frag. AFAIK that has never been a valid config
option (there are some color.interactive.* values, but they are all for
interactive-specific things).
So something like this seems to go in the right direction (and makes
your example work):
diff --git a/add-interactive.c b/add-interactive.c
index a14c0feaa2..1eb69c5160 100644
--- a/add-interactive.c
+++ b/add-interactive.c
@@ -12,10 +12,11 @@
#include "prompt.h"
static void init_color(struct repository *r, struct add_i_state *s,
+ const char *section,
const char *slot_name, char *dst,
const char *default_color)
{
- char *key = xstrfmt("color.interactive.%s", slot_name);
+ char *key = xstrfmt("color.%s.%s", section, slot_name);
const char *value;
if (!s->use_color)
@@ -40,18 +41,19 @@ void init_add_i_state(struct add_i_state *s, struct repository *r)
git_config_colorbool("color.interactive", value);
s->use_color = want_color(s->use_color);
- init_color(r, s, "header", s->header_color, GIT_COLOR_BOLD);
- init_color(r, s, "help", s->help_color, GIT_COLOR_BOLD_RED);
- init_color(r, s, "prompt", s->prompt_color, GIT_COLOR_BOLD_BLUE);
- init_color(r, s, "error", s->error_color, GIT_COLOR_BOLD_RED);
- init_color(r, s, "reset", s->reset_color, GIT_COLOR_RESET);
- init_color(r, s, "fraginfo", s->fraginfo_color,
+ init_color(r, s, "interactive", "header", s->header_color, GIT_COLOR_BOLD);
+ init_color(r, s, "interactive", "help", s->help_color, GIT_COLOR_BOLD_RED);
+ init_color(r, s, "interactive", "prompt", s->prompt_color, GIT_COLOR_BOLD_BLUE);
+ init_color(r, s, "interactive", "error", s->error_color, GIT_COLOR_BOLD_RED);
+
+ init_color(r, s, "diff", "reset", s->reset_color, GIT_COLOR_RESET);
+ init_color(r, s, "diff", "frag", s->fraginfo_color,
diff_get_color(s->use_color, DIFF_FRAGINFO));
- init_color(r, s, "context", s->context_color,
+ init_color(r, s, "diff", "context", s->context_color,
diff_get_color(s->use_color, DIFF_CONTEXT));
- init_color(r, s, "old", s->file_old_color,
+ init_color(r, s, "diff", "old", s->file_old_color,
diff_get_color(s->use_color, DIFF_FILE_OLD));
- init_color(r, s, "new", s->file_new_color,
+ init_color(r, s, "diff", "new", s->file_new_color,
diff_get_color(s->use_color, DIFF_FILE_NEW));
FREE_AND_NULL(s->interactive_diff_filter);
but that is missing another thing: for historical reasons we allow both
color.diff.frag and diff.color.frag. TBH, I wouldn't be too sad to see
us drop support for the historical versions in this setting. But it
makes me wonder if we could be reusing the parsing from
git_diff_basic_config(), which handles both cases.
I'm not entirely clear on how add-interactive.c invokes the diff, and
whether it would be unhappy to pick up diff config. But it seems like
this:
diff --git a/builtin/add.c b/builtin/add.c
index a825887c50..47bb6ea10b 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -362,7 +362,7 @@ static int add_config(const char *var, const char *value, void *cb)
return 0;
}
- return git_default_config(var, value, cb);
+ return git_diff_basic_config(var, value, cb);
}
static const char embedded_advice[] = N_(
might be the simplest thing (and drop the extra diff-config parsing from
add-interactive.c that I was touching above). It does need to be done in
each program that calls into the add-interactive code though (so
checkout, etc). Obviously it would be easy for init_add_i_state() to
make a similar call, though that may open us up to loading the diff
config twice. I suspect that would probably be OK, but it could lead to
weirdness if there are any multi-valued config options.
-Peff
next prev parent reply other threads:[~2020-11-06 17:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 16:31 ["BUG"] builtin add-interactive does not honor 'color.diff. frag' Philippe Blain
2020-11-06 17:03 ` Jeff King [this message]
2020-11-10 16:06 ` Johannes Schindelin
2020-11-10 18:01 ` Jeff King
2020-11-10 18:28 ` [PATCH] add-interactive.c: use correct names to load color.diff.* config Jeff King
2020-11-10 19:17 ` Johannes Schindelin
2020-11-10 19:48 ` Jeff King
2020-11-10 22:30 ` 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=20201106170345.GA174555@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=levraiphilippeblain@gmail.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 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 NNTP newsgroup(s).