git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Tom Hale <tom@hale.ee>, git <git@vger.kernel.org>,
	Duy Nguyen <pclouds@gmail.com>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: %C(auto) not working as expected
Date: Sun, 9 Oct 2016 19:46:18 -0400	[thread overview]
Message-ID: <20161009234617.y6xfjyv6xjkf2afi@sigill.intra.peff.net> (raw)
In-Reply-To: <25c17e16-2456-7da3-ae22-2dc812a3aa0d@web.de>

On Sun, Oct 09, 2016 at 03:24:17PM +0200, René Scharfe wrote:

> Offering a way to enable terminal-detection for all color codes of a
> format would be useful, but using the existing "auto," prefix for that
> would be a behaviour change that could surprise users.

Yeah. In retrospect, it probably would have been saner to make %C(red) a
noop when --color is not in effect (either because of --no-color, or
more likely when --color=auto is in effect and stdout is not a
terminal). But that ship has long since sailed, I think.

If we do a revamp of the pretty-formats to bring them more in line with
ref-filter (e.g., something like "%(color:red)") maybe that would be an
opportunity to make minor adjustments. Though, hmm, it looks like
for-each-ref already knows "%(color:red)", and it's unconditional.
<sigh> So perhaps we would need to go through some deprecation period or
other transition.

> ---
>  Documentation/pretty-formats.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index a942d57..89e3bc6 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -166,7 +166,8 @@ endif::git-rev-list[]
>  - '%Cgreen': switch color to green
>  - '%Cblue': switch color to blue
>  - '%Creset': reset color
> -- '%C(...)': color specification, as described in color.branch.* config option;
> +- '%C(...)': color specification, as described under Values, color in the
> +  "CONFIGURATION FILE" section of linkgit:git-config[1];

I like the intent here, though I found "Values, color" hard to parse (it
was not immediately clear that you mean "the color paragraph of the
Values section", as commas are already being used in that sentence for
the parenthetical phrase).

I'm not sure how to say that succinctly, as we are four levels deep
(git-config -> configuration file -> values -> color). Too bad there is
no good link syntax for it. Maybe:

  ...color specification, as described in linkgit:git-config[1] (see the
  paragraph on colors in the "Values" section, under "CONFIGURATION
  FILE")

or something.

-Peff

  reply	other threads:[~2016-10-09 23:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-09  5:43 %C(auto) not working as expected Tom Hale
2016-10-09  6:47 ` René Scharfe
2016-10-09 10:04   ` Tom Hale
2016-10-09 13:24     ` René Scharfe
2016-10-09 23:46       ` Jeff King [this message]
2016-10-10  9:26         ` Duy Nguyen
2016-10-10 14:28           ` Jeff King
2016-10-10 15:15             ` [PATCH] pretty: respect color settings for %C placeholders Jeff King
2016-10-10 17:09               ` René Scharfe
2016-10-10 17:42                 ` Jeff King
2016-10-10 19:59                   ` René Scharfe
2016-10-10 20:04                     ` Jeff King
2016-10-10 18:52               ` Junio C Hamano
2016-10-10 18:59                 ` Jeff King
2016-10-10 20:54                   ` Jeff King
2016-10-11 10:59               ` Duy Nguyen
2016-10-25 12:52             ` %C(auto) not working as expected Duy Nguyen
2016-10-25 12:58               ` Jeff King
2016-10-25 13:02                 ` Duy Nguyen
2016-10-10 20:52         ` René Scharfe
2016-10-10 20:55           ` Jeff King
2016-10-11  3:41             ` [PATCH v2] pretty: fix document link for color specification René Scharfe
2016-10-11  4:45               ` Jeff King

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=20161009234617.y6xfjyv6xjkf2afi@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=pclouds@gmail.com \
    --cc=tom@hale.ee \
    /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).