From: Mark Lodato <lodatom@gmail.com>
Date: Fri, 05 Mar 2010 01:32:08 GMT
Subject: Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)
Message-ID: <ca433831003041732k69c7cadcuf8f7feaabf3e372f@mail.gmail.com>
In-Reply-To: <ca433831003041730w7ccbc953kad3b600e7b112e0e@mail.gmail.com>

On Thu, Mar 4, 2010 at 8:30 PM, Mark Lodato <lodatom@gmail.com> wrote:
> On Wed, Mar 3, 2010 at 7:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * ml/color-grep (2010-02-26) 3 commits
>>  - grep: Colorize selected, context, and function lines
>>  - grep: Colorize filename, line number, and separator
>>  - Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*
>>
>> There was a comment about not special casing filename coloring?
>
> The disagreement is whether --name-only output should be colored or
> not.  In the patch, it is not, which I argue makes more sense.  When
> --name-only is given, the only thing output is filenames.  Having them
> all be the same color adds no information, and I personally find it
> annoying to see one big block of the same color. GNU grep does color
> the filenames with --name-only.  Michael Witten argues that this makes
> the output consistent: whenever it's a filename, it's colored. [1]  He
> also thinks that matching GNU grep's behavior is important.  He didn't
> convince me and I didn't convince him, so it would be nice to have
> more opinions on this.

Sorry, forgot the footnote:

[1] Except that GNU grep does not color the filename is "Binary file
<file> matches."  This patch does color it.