Jeff King <peff@peff.net> writes:

quoted text
>> +	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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html