All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike McGranahan <mike@mcgwiz.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Patch text in git-add patch mode lacks whitespace highlighting
Date: Fri, 31 Jan 2020 16:48:10 -0800	[thread overview]
Message-ID: <CAK7jxYjLoXZhRzUWERmJg9ADNhvJt5SLLymPVktiWcT4RC6VpA@mail.gmail.com> (raw)
In-Reply-To: <20200131091917.GC2857810@coredump.intra.peff.net>

I can confirm this fixes the unexpected behavior I reported. (Thanks!)
I can't speak directly to the plumbing as I don't regularly use thos
tools.

-Mike

On Fri, Jan 31, 2020 at 1:19 AM Jeff King <peff@peff.net> wrote:
>
> On Thu, Jan 30, 2020 at 01:53:52PM -0800, Mike McGranahan wrote:
>
> > I'm using version 2.25.0.windows.1. If I set config "wsErrorHighlight"
> > to "old", and run `git diff -p`, the resulting patch text highlights
> > whitespace differences in the old text.
> >
> > If I then run git-add in interactive patch mode, I expect the diff to
> > include the whitespace highlights. But actually, it does not.
> >
> > Is this a bug? Thanks for your help.
>
> Sort of. It's more of a feature that has not yet been implemented. ;)
>
> Like the rest of the color config, diff.wsErrorHighlight is not enabled
> for scriptable plumbing commands like git-diff-index, etc; it is only
> used for the user-facing porcelain commands like git-diff.
>
> So scripts like git-add--interactive, which use the plumbing under the
> hood, are responsible for deciding which config options should be
> respected and passing the correct command-line options on to the
> plumbing. We do that for color.diff, diff.algorithm, and a few others.
> But nobody has yet taught it that diff.wsErrorHighlight is safe to pass
> (for the user-facing "color" version of the diff).
>
> The solution for the existing perl script would be something like this:
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index c4b75bcb7f..fac1d1e63e 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -46,6 +46,7 @@
>  my $normal_color = $repo->get_color("", "reset");
>
>  my $diff_algorithm = $repo->config('diff.algorithm');
> +my $diff_error_highlight = $repo->config('diff.wsErrorHighlight');
>  my $diff_filter = $repo->config('interactive.difffilter');
>
>  my $use_readkey = 0;
> @@ -727,7 +728,11 @@ sub parse_diff {
>         my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
>         my @colored = ();
>         if ($diff_use_color) {
> -               my @display_cmd = ("git", @diff_cmd, qw(--color --), $path);
> +               my @display_cmd = ("git", @diff_cmd, qw(--color),
> +                                  $diff_error_highlight ?
> +                                    "--ws-error-highlight=$diff_error_highlight" :
> +                                    (),
> +                                  qw(--), $path);
>                 if (defined $diff_filter) {
>                         # quotemeta is overkill, but sufficient for shell-quoting
>                         my $diff = join(' ', map { quotemeta } @display_cmd);
>
> but this is all being rewritten in C. I'm not sure how the multiple
> diffs are being handled there.
>
> 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).
>
> -Peff

  parent reply	other threads:[~2020-02-01  0:48 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   ` [PATCH] diff: move diff.wsErrorHighlight to "basic" config Jeff King
2020-02-01  0:48   ` Mike McGranahan [this message]
2020-01-31 12:37 ` Patch text in git-add patch mode lacks whitespace highlighting 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=CAK7jxYjLoXZhRzUWERmJg9ADNhvJt5SLLymPVktiWcT4RC6VpA@mail.gmail.com \
    --to=mike@mcgwiz.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.