git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Todd Zullinger <tmz@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	Zefram <zefram@fysh.org>
Subject: Re: [PATCH] diff-tree: obey the color.ui configuration
Date: Fri, 29 Dec 2017 20:55:33 -0500	[thread overview]
Message-ID: <20171230015533.GA27130@sigill.intra.peff.net> (raw)
In-Reply-To: <20171229231631.GS3693@zaya.teonanacatl.net>

On Fri, Dec 29, 2017 at 06:16:31PM -0500, Todd Zullinger wrote:

> Ævar Arnfjörð Bjarmason wrote:
> > No idea how to test this, in particular trying to pipe the output of
> > color.ui=never v.s. color.ui=auto to a file as "auto" will disable
> > coloring when it detects a pipe, but this fixes the issue.
> 
> You might be able to use similar methods as those Jeff used
> in the series merged from jk/ui-color-always-to-auto:
> 
> https://github.com/gitster/git/tree/jk/ui-color-always-to-auto

Yeah, test_terminal is the solution to testing. But...

> He may also have some ideas about this issue in general.
> (Or they could be tramatic memories, depending on how
> painful it was to dig into the color code.)

Yep. If we make diff-tree support color.ui, it's going to break a bunch
of other stuff (like add--interactive) for people who set color.ui=always.
I know this empirically, because we did that in v2.13, and a bunch of
people complained. ;)

The root of the problem is that the plumbing diff-tree defaults its
internal color variable to "auto" in the first place. In theory the best
way forward is fixing that, but it's likely to have a bunch of fallouts
itself (scripts which use plumbing and where the user _does_ want color
will stop showing it). This bug has been around since v1.8.4, I think,
so it's hard to say how many people are depending on it at this point.

A hackier option which would probably make most people happy would be to
have plumbing respect "color.ui=never", but not any other values.

I think the history of the back and forth is:

  - 4c7f1819b3 (make color.ui default to 'auto', 2013-06-10) introduced
    the problem of plumbing defaulting to "auto". This was in v1.8.4.

  - we did something similar to Ævar's patch in 136c8c8b8f (color: check
    color.ui in git_default_config(), 2017-07-13). That shipped in
    v2.14.2, and people with color.ui=always complained, because things
    like add--interactive broke for them.

  - we tried fixing it with 6be4595edb (color: make "always" the same as
    "auto" in config, 2017-10-03), but that broke people doing "git -c
    color.ui=always" as an equivalent of "--color". We talked about
    making the "-c" config behave differently from on-disk config, but
    got pretty disgusted at the weird hacks. And so...

  - we ended up with 33c643bb08 (Revert "color: check color.ui in
    git_default_config()", 2017-10-13), which just reverts the whole
    mess back to the pre-v2.14 state. This shipped in v2.15.

So I don't think we want to go down that road again. If anything, we
want to either fix the original sin from 4c7f1819b3, or we want to do
the "respect only never" hack.

-Peff

  reply	other threads:[~2017-12-30  1:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-29 19:47 [BUG] git bisect colour output contrary to configuration Zefram
2017-12-29 22:05 ` Ævar Arnfjörð Bjarmason
2017-12-29 22:51   ` [PATCH] diff-tree: obey the color.ui configuration Ævar Arnfjörð Bjarmason
2017-12-29 23:16     ` Todd Zullinger
2017-12-30  1:55       ` Jeff King [this message]
2017-12-30 12:33         ` Ævar Arnfjörð Bjarmason
2017-12-30 14:45           ` Jeff King
2017-12-30 15:04             ` Ævar Arnfjörð Bjarmason
2017-12-30 18:15               ` Jeff King
2017-12-30 23:01                 ` Christian Couder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171230015533.GA27130@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tmz@pobox.com \
    --cc=zefram@fysh.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).