From: Jeff King <peff@peff.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: git@vger.kernel.org
Subject: Re: rfe: git-config: lack of color reset option
Date: Mon, 20 Feb 2012 16:20:06 -0500 [thread overview]
Message-ID: <20120220212006.GB6335@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.LNX.2.01.1202202142160.31585@frira.zrqbmnf.qr>
On Mon, Feb 20, 2012 at 09:50:11PM +0100, Jan Engelhardt wrote:
> given the following config:
>
> [color "diff"]
> commit = bold white blue
> [color "decorate"]
> branch = green
>
> The attributes from color.diff.commit are inherited for color.decorate.
This is an artifact of the way the ANSI colorizing works. Git says "turn
on bold white and a blue background", then it outputs some content, then
it says "turn on green", and so forth. At the end we issue a "reset" to
turn everything back to normal. We should perhaps issue a reset before
outputting the decoration, as we are moving from one colorized bit to
the other, and we don't know what we are inheriting.
Of course that would break people who _want_ the blue background to
continue into the branch decoration. But they can easily fix it by
putting "green blue" in their config.
> 1. There seems to be no way to reset the attributes such that
> "color.decorate.branch = default green blue" wouuld have an effect.
I would have expected that perhaps setting color.decorate.branch to
"reset green" would work, but it seems that we don't allow arbitrary
sequences. Which would be another possible solution.
In your case, I think you just want turn off bold without resetting the
whole thing. That is its own attribute. It would be nice if we supported
"nobold", "noreverse", etc. But you wouldn't really need them if we
properly reset at the transition between two colorized bits.
> 2. It would be nice if there was an option to only paint the
> commit hash, rather than the entire line including the decorate
> parenthesis group.
Yeah, the parentheses are explicitly painted. I'm not sure how to easily
fix that short of adding lots of painfully small config options.
I have a long term dream that our --pretty=format specifiers would grow
featureful enough that all of the other --pretty formats could be
implemented in terms of them. And then you could tweak to your hearts
content, starting with the embedded definition of what "git log" shows
and putting colors wherever you like. I'm not sure how far we are off
from doing that now. You could try writing a format-specifier that looks
like git-log output and see if there is anything lacking.
-Peff
next prev parent reply other threads:[~2012-02-20 21:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 20:50 rfe: git-config: lack of color reset option Jan Engelhardt
2012-02-20 21:20 ` Jeff King [this message]
2012-02-20 22:05 ` Junio C Hamano
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=20120220212006.GB6335@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jengelh@medozas.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).