Re: [PATCH] diff.c: offer config option to control ws handling in move detection

From: Stefan Beller <sbeller@google.com>
Date: Jul 19, 2018, 18:00 UTC
Message-ID: <CAGZ79kYo_zFfvX1LHod47BND=GbmzeaBfxhLbX_nmCPx0UATZQ@mail.gmail.com>
In-Reply-To: <xmqq601bgmh3.fsf@gitster-ct.c.googlers.com>

On Thu, Jul 19, 2018 at 10:32 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> Stefan Beller <sbeller@google.com> writes:
>
> > "git format-patch HEAD^ --color" produces red/green output
> > (like git log would), so I do not see why --color-moved should impact
> > format-patch differently. (i.e. if the user requests format-patch with
> > color-moved we can do it, otherwise, when colors are off, we do not
> > spend cycles to compute the moves)
> >
> > Maybe I did not understand the gist of your question, still?
>
> "format-patch --color" done by end-user, especially when combined
> with "--stdout", would be useful to show coloured output.  That is
> what you are talking about in the above, but that is not what I was
> asking about.
>
> The question was specifically about configuration.  You may say
> "diff.colorwhatever = on", but "git format-patch" with no command
> line override wouldn't want to be affected by that and produce a
> patch that won't apply, I would think.

The options introduced here (even the command line arguments) do *nothing* if no color is on, i.e.

    git diff --no-color --color-moved=blocks \
        --color-moved-ws=allow-indentation-change

is the same as

    git diff --no-color

and as format-patch doesn't use colors by default giving color-moved settings (even via config) is a no-op, too?

Stefan