From: Jeff King Date: Wed, 18 Feb 2015 23:07:29 GMT Subject: Re: [PATCH] log --decorate: do not leak "commit" color into the next item Message-ID: <20150218230728.GA17302@peff.net> In-Reply-To: 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 > --- 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