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

Jeff King [off-list ref] writes:

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").

Hmph, but that $gmane/191118 talks about giving bold to commit-color
and then expecting for decors to inherit the boldness, a wish I can
understand.  But I do not necessarily agree with it---it relies on
that after "<commit-color>(" and "<commit-color>, " there is no reset,
which is not how everything else works.

So this change at least needs to come with an explanation to people
who are used to and took advantage of this color attribute leakage,
definitely in the log message and preferrably to the documentation
that covers all the color.*.<slot> settings, I think.

Thanks.