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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 22, 2007, 21:37 UTC
Message-ID: <7v1wai3qrw.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20071122122540.GH12913@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

>> +	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.