Re: What's in git.git and announcing v1.4.1-rc1

From: Junio C Hamano <junkio@cox.net>
Date: Jun 22, 2006, 22:07 UTC
Message-ID: <7v7j38j144.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0606221301500.5498@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 6 quoted lines

> On Thu, 22 Jun 2006, Junio C Hamano wrote:
>> 
>>  - diff --color (Johannes).
>
> I like colorized diffs, but let's face it, those particular color choices 
> will make most people decide to pick out their eyes with a fondue fork.

Well, I admit I do not use colorized diffs myself. As a matter of fact, I use specialized terminfo to disable coloring on my terminal session, since fontifying in GNUS otherwise gives me unreadable screen and I am too lazy to figure out how to turn it off.

I do however usually test colored stuff with at least white and black backgrounds,

> This patch does:
>
>  - always reset the color _before_ printing out the newline.

Sorry, although I did notice this (interrupting a long diff, or running it with "less -r" and quitting it would leave the terminal in funny color), I did not bother to fix it.

>  - default to red/green for old/new lines. That's the norm, I'd think.

OK.

>  - instead of that eye-popping (and eye-ball-with-a-fondue-fork-popping) 
>    purple color for metadata, use bold-face for file headers, and cyan for 
>    the frag headers. I actually prefer the "gray background" for that, but 
>    it only works well in xterms, so COLOR_CYAN it is..

Replacing it with COLOR_GRAYBG did not work out too well with either xterm nor kterm for me, although it did work under gnome-terminal.

Cyan foreground color is unreadable on white background and that was why I did magenta in my original patch, but it may be just that I am color challenged in that spectrum.