Traditionally, %C(color attr) always emitted the ANSI color
sequence; it was up to the scripts that wanted to conditionally
color their output to omit %C(...) specifier when they do not want
colors.
Optionally allow auto, to be prefixed to the color, so that the
output is colored iff it goes to
On Mon, Dec 17, 2012 at 3:40 PM, Junio C Hamano gits...@pobox.com wrote:
Traditionally, %C(color attr) always emitted the ANSI color
sequence; it was up to the scripts that wanted to conditionally
color their output to omit %C(...) specifier when they do not want
colors.
Optionally allow
Jeff King p...@peff.net writes:
On Mon, Dec 17, 2012 at 06:44:10PM +0700, Nguyen Thai Ngoc Duy wrote:
if (!end)
return 0;
- color_parse_mem(placeholder + 2,
- end -
On Mon, Dec 17, 2012 at 11:34:48AM -0800, Junio C Hamano wrote:
Yeah, that should definitely be documented. I wonder if it should
actually respect color.diff, which is what log usually uses (albeit
mostly for the diff itself, we have always used it for the graph and for
the commit header
Jeff King p...@peff.net writes:
If git frotz wants to have a separate color.frotz option to override
that, then they would need to implement that themselves either with or
without your patch. I do not think its presence makes things any harder.
That _was_ (but no longer is) exactly my point.
On Mon, Dec 17, 2012 at 12:03:40PM -0800, Junio C Hamano wrote:
So no, I do not think you can cover every conceivable case. But having
git-log respect --color and the usual color.* variables for this feature
seems like the only sane default. It makes the easy cases just work, and
the hard
6 matches
Mail list logo
