From: Thomas Egerer <thomas.egerer@secunet.com>
To: Will Palmer <wmpalmer@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] pretty.c: Make user defined format honor color option
Date: Thu, 17 Mar 2011 13:02:40 +0100 [thread overview]
Message-ID: <4D81F860.2070703@secunet.com> (raw)
In-Reply-To: <1300354791.3269.19.camel@wpalmer.simply-domain>
On 03/17/2011 10:39 AM, Will Palmer schrobtete:
> On Thu, 2011-03-17 at 09:33 +0100, Thomas Egerer wrote:
>> This patch fixes that the pretty-formats tformat and format ignore
>> git's color option.
>
> It is my understanding that this is intentional, the logic being: If you
> normally don't want color, but have specified it directly on the
> command-line, you probably want color.
I'm using the pretty format in the context of an alias. My global setting
for colors is auto. I would expect git to not disregard this options. I
usually use the alias to display a git log in a modified way, but I also
do sometimes pipe it to grep. If there was a way to suppress output
colorization (let's say by not using global options but the command line
switch --color=never) that would work for me. But there is no wa and I
find it inconvinient to have two different aliases doing the same thing
one with color and one without while there would be a much simpler way.
> iirc, there are a couple of other places beyond log-tree.c which need to
> propagate COLOR_DIFF into the pretty context if you want to respect the
> colour option in user-specified formats. Skimming my own diffs:
> rev-list.c and shortlog.c
You're right. If there's a chance to bring this upstream, I would include
it in a revised versoin of my patch.
Thomas
next prev parent reply other threads:[~2011-03-17 12:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 8:33 [PATCH] pretty.c: Make user defined format honor color option Thomas Egerer
2011-03-17 9:39 ` Will Palmer
2011-03-17 12:02 ` Thomas Egerer [this message]
2011-03-17 12:59 ` Will Palmer
2011-03-17 19:49 ` Jeff King
2011-03-17 13:46 ` Thomas Egerer
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=4D81F860.2070703@secunet.com \
--to=thomas.egerer@secunet.com \
--cc=git@vger.kernel.org \
--cc=wmpalmer@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.