From: Jeff King <peff@peff.net>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: Junio C Hamano <gitster@pobox.com>,
Markus Heidelberg <markus.heidelberg@web.de>,
git@vger.kernel.org
Subject: Re: [PATCH 2/2] expand --pretty=format color options
Date: Sun, 18 Jan 2009 14:43:28 -0500 [thread overview]
Message-ID: <20090118194328.GA31180@coredump.intra.peff.net> (raw)
In-Reply-To: <20090118173753.GB17434@coredump.intra.peff.net>
On Sun, Jan 18, 2009 at 12:37:53PM -0500, Jeff King wrote:
> On Sun, Jan 18, 2009 at 06:13:21PM +0100, René Scharfe wrote:
> > Another step would be for --pretty=format to respect the color config,
> > i.e. it shouldn't print any colour codes if colouring is turned off or
> > if set to auto while writing to file or pipe.
>
> That makes sense to me. In theory, we could offer an "always use this
> color" and a "conditionally use this color" substitution. But I don't
> really see why anyone would want the "always use this color" one (they
> could just say --color, then).
Here is a patch that seems to work. It predicates pretty format colors
on diff colors, which is the same way the yellow commit header works in
log-tree. I don't know if it makes more sense to introduce yet another
color config option.
And I say "seems to work" because I remember there being some trickery
with color flags sometimes not getting set properly. However, since this
is the same flag as the yellow commit header, and called around the same
time, I think it should be fine.
One final note: if you are writing "generic" format strings, you
probably don't want to say "yellow". You want to say "whatever the user
has configured for color.diff.commit". I don't know if %C should be
overloaded for that or not (i.e., %C(commit) would be a valid color).
-- >8 --
respect color settings for --pretty=format colors
Previously, we would unconditionally print any colors the
user put into the --pretty=format specifier, regardless of
the setting of color configuration. This is not a problem if
the user writes a custom string each time git-log is
invoked. However, it makes use in scripts unnecessarily
complex, since they would have to change the format string
based on user preferences (and whether output is going to a
tty).
This patch will ignore any colors in --pretty=format if diff
colors are not turned on (they will still be parsed and
treated as placeholders, but no color will be output). This
matches the color.diff.commit colorization, which depends on
diff coloring even though it is not technically part of a
diff.
---
pretty.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/pretty.c b/pretty.c
index b1b8620..fe606c5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -563,20 +563,25 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
color_parse_mem(placeholder + 2,
end - (placeholder + 2),
"--pretty format", color);
- strbuf_addstr(sb, color);
+ if (diff_use_color_default)
+ strbuf_addstr(sb, color);
return end - placeholder + 1;
}
if (!prefixcmp(placeholder + 1, "red")) {
- strbuf_addstr(sb, "\033[31m");
+ if (diff_use_color_default)
+ strbuf_addstr(sb, "\033[31m");
return 4;
} else if (!prefixcmp(placeholder + 1, "green")) {
- strbuf_addstr(sb, "\033[32m");
+ if (diff_use_color_default)
+ strbuf_addstr(sb, "\033[32m");
return 6;
} else if (!prefixcmp(placeholder + 1, "blue")) {
- strbuf_addstr(sb, "\033[34m");
+ if (diff_use_color_default)
+ strbuf_addstr(sb, "\033[34m");
return 5;
} else if (!prefixcmp(placeholder + 1, "reset")) {
- strbuf_addstr(sb, "\033[m");
+ if (diff_use_color_default)
+ strbuf_addstr(sb, "\033[m");
return 6;
} else
return 0;
--
1.6.1.151.g5a7da.dirty
next prev parent reply other threads:[~2009-01-18 19:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 15:06 [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that Baz
2009-01-17 1:40 ` Jeff King
2009-01-17 12:37 ` Markus Heidelberg
2009-01-17 15:21 ` Jeff King
2009-01-17 15:32 ` [PATCH 1/2] color: make it easier for non-config to parse color specs Jeff King
2009-01-18 17:10 ` René Scharfe
2009-01-18 17:28 ` Jeff King
2009-01-18 17:36 ` Jeff King
2009-01-18 17:45 ` René Scharfe
2009-01-18 18:06 ` Jeff King
2009-01-17 15:38 ` [PATCH 2/2] expand --pretty=format color options Jeff King
2009-01-18 17:13 ` René Scharfe
2009-01-18 17:37 ` Jeff King
2009-01-18 19:43 ` Jeff King [this message]
2009-01-18 19:53 ` Jeff King
2009-01-18 20:37 ` [PATCH 1/2] handle color.ui at a central place Markus Heidelberg
2009-01-18 20:39 ` [PATCH 2/2] move the color variables to color.c Markus Heidelberg
2009-01-20 4:04 ` [PATCH 1/2] handle color.ui at a central place Jeff King
2009-01-21 22:35 ` Markus Heidelberg
2009-01-22 0:00 ` Jeff King
2009-01-22 0:13 ` Markus Heidelberg
2009-01-23 6:13 ` Junio C Hamano
2009-01-24 11:28 ` Markus Heidelberg
2009-01-24 14:14 ` Johannes Schindelin
2009-01-24 14:23 ` Markus Heidelberg
2009-01-24 18:36 ` Junio C Hamano
2009-01-24 19:17 ` Jeff King
2009-01-24 20:26 ` Junio C Hamano
2009-01-24 20:45 ` Jeff King
2009-01-25 14:15 ` Markus Heidelberg
2009-01-19 23:10 ` [PATCH 2/2] expand --pretty=format color options Junio C Hamano
2009-01-20 4:06 ` Jeff King
2009-01-20 10:27 ` Johannes Schindelin
2009-01-20 10:36 ` Johannes Schindelin
2009-01-20 14:23 ` Jeff King
2009-01-20 14:58 ` Johannes Schindelin
2009-01-20 19:21 ` Jeff King
2009-01-17 15:39 ` Cyellow, was Re: [a way-too-long line] Johannes Schindelin
2009-01-17 15:40 ` Jeff King
2009-01-17 15:46 ` 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=20090118194328.GA31180@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=markus.heidelberg@web.de \
--cc=rene.scharfe@lsrfire.ath.cx \
/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).