Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)
- From
Mark Lodato <lodatom@gmail.com>
- Date
- Mar 5, 2010, 01:32 UTC
- 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:
Show 18 quoted lines
> 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.