Re: [PATCH] log --decorate: do not leak "commit" color into the next item

[Jeff King <peff@peff.net>]

On Wed, Feb 18, 2015 at 01:44:54PM -0800, Junio C Hamano wrote:

> If you wanted to paint the HEAD and local branch name in the same
> color as the body text (perhaps because cyan and green are too faint
> on a black-on-white terminal to be readable), you would not want to
> have to say
> 
>     [color "decorate"]
>         head = black
>         branch = black
> 
> because that you would not be able to reuse same configuration on a
> white-on-black terminal.  You would naively expect
> 
>     [color "decorate"]
>         head = normal
> 	branch = normal
> 
> to work, but unfortunately it does not.  It paints the string "HEAD"
> and the branch name in the same color as the opening parenthesis or
> comma between the decoration elements when showing output like this:
> 
>     $ git show -s --decorate
>     commit f3f407747c1cce420ae4b4857c4a6806efe38680 (HEAD, master)
>     ...
> 
> This is because the code forgets to reset the color after printing
> the "prefix" in its own color.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---

Yeah, I think this is a good fix. I had a vague feeling that we may have
done this on purpose to let the decoration color "inherit" from the
existing colors for backwards compatibility, but I don't think that
could ever have worked (since color.decorate.* never defaulted to
"normal"). And I couldn't find anything on the list. I think I am
probably thinking of color.diff.func, which faced a similar issue.

Also, for your amusement:

  http://thread.gmane.org/gmane.comp.version-control.git/191102/focus=191118

Believe it or not, this was actually an item on my todo list, which is
perhaps a commentary on how sad and unrealistic my todo list is. But I'm
crossing it off anyway. Task accomplished!

-Peff