Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html