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

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 <redacted>
---

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