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

On Thu, Feb 19, 2015 at 10:02:12AM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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.

I don't see anybody actually _wanting_ the inheritance. It is mentioned
merely as an observation. So yeah, we would break anybody who does:

  [color "diff"]
  commit = blue

  [color "decorate"]
  branch = normal
  remoteBranch = normal
  tag = normal
  stash = normal
  HEAD = normal

and expects the "blue" to persist automatically.

But given that this behaves in the opposite way of every other part of
git's color handling, I think we can call it a bug, and people doing
that are crazy (they should s/normal/blue/ in the latter config).

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.

I'd agree it is worth a mention in the log (and possibly release notes),
but I don't think it is worth polluting the documentation forever
(though explaining that we never inherit might be worth doing, and that
is perhaps what you meant).

-Peff