Jeff King <peff@xxxxxxxx> writes:
>> + if ($diff_use_color) {
>> + $new_color = get_color('color.diff.new', 'green');
>> + $old_color = get_color('color.diff.old', 'red');
>> + $fraginfo_color = get_color('color.diff.frag', 'cyan');
>> + $metainfo_color = get_color('color.diff.meta', 'bold');
>> + $normal_color = Git::color_to_ansi_code('normal');
>> + # Not implemented:
>> + #$whitespace_color = get_color('color.diff.whitespace',
>> + #'normal red');
>
> Unfortunately, there is a historical wart that probably still needs
> supporting, which is that the original names were diff.color.*. Or have
> we officially removed support for that yet?
Neither officially or unofficially yet, but we can start the
process of making it official with an early announcement. I do
not think we would hurt people as long as a long enough advance
notice is given.
I however am wondering if we need to have so many "enable color
support" switches. color.status, color.diff, and now yet
another color.interactive? Who sets color.status and/or
color.interactive to auto without setting color.diff to auto as
well?
It may be good that they _can_ be individually controlled, but I
strongly suspect that most people would just want to set a
single variable color.ui to "auto", and have it give the default
value for all the color.$cmd configuration variable that are not
explicitly defined.
-
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
