Jeff King <> 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.  Eh, rather, its
absense does not make things any harder.

> 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 cases are not any worse off (and they may even be better off,
> since the script can manipulate --color instead of rewriting their
> format strings, but that is a minor difference).

OK, care to reroll the one with your patch in the other message
squashed in, possibly with fixes to the test (the result should now
honor --color={always,never}, I think)?


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to