Re: [PATCH 5/5] Added diff hunk coloring to git-add--interactive

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.