From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <johannes.schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] diff: let --output=<file> default to --no-color
Date: Fri, 24 Jun 2016 15:14:11 -0700 [thread overview]
Message-ID: <xmqqshw2dyks.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <100cea0edf4f0986c000eb945a5e5955b8b59787.1466604435.git.johannes.schindelin@gmx.de> (Johannes Schindelin's message of "Wed, 22 Jun 2016 16:41:07 +0200 (CEST)")
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> It is highly unlikely that any user would want to see ANSI color
> sequences in a file. So let's stop doing that by default.
>
> This is a backwards-incompatible change.
>
> The reason this was not caught earlier is most likely that either
> --output=<file> is not used, or only when stdout is redirected
> anyway.
>
> Technically, we do not default to --no-color here. Instead, we try to
> override the GIT_COLOR_AUTO default because it would let want_color()
> test whether stdout (instead of the specified file) is connected to a
> terminal. Practically, we require the user to require color "always"
> to force writing ANSI color sequences to the output file.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Published-As: https://github.com/dscho/git/releases/tag/diff-o-v1
>
> Just something I noted while working on a bit more consistency
> with the diffopt.file patches.
>
> This is a backwards-incompatible change, though. So I extracted it
> from the patch series.
I think this is a bugfix. Even though we are writing to a file that
is separate from the standard output (because we explicitly opened
that file outselves), --color=auto would still let want_color() make
the decision based on isatty(1) with hardcoded 1. That does not
simply make sense.
If we imagine that your format-patch series with 06/10 and 07/10
swapped, then the "do not freopen(), instead point opened file with
diffopt.file" step would be seen as introducing the same bug as the
bug this patch fixes, so in that sense it is an equivalent to 06/10.
We do not need to view this patch as a compatibility-breaking
change, I would think.
Perhaps I should tweak 06/10 to assign GIT_COLOR_NEVER not 0 while
queuing it.
Thanks.
> diff.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/diff.c b/diff.c
> index fa78fc1..b66b9be 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3977,6 +3977,8 @@ int diff_opt_parse(struct diff_options *options,
> if (!options->file)
> die_errno("Could not open '%s'", path);
> options->close_file = 1;
> + if (options->use_color != GIT_COLOR_ALWAYS)
> + options->use_color = GIT_COLOR_NEVER;
> return argcount;
> } else
> return 0;
next prev parent reply other threads:[~2016-06-24 22:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-22 14:41 [PATCH] diff: let --output=<file> default to --no-color Johannes Schindelin
2016-06-24 22:14 ` Junio C Hamano [this message]
2016-06-26 6:57 ` 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=xmqqshw2dyks.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
/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).