From: Mark Lodato <lodatom@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Witten <mfwitten@gmail.com>
Subject: Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)
Date: Thu, 4 Mar 2010 20:32:08 -0500 [thread overview]
Message-ID: <ca433831003041732k69c7cadcuf8f7feaabf3e372f@mail.gmail.com> (raw)
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.
next prev parent reply other threads:[~2010-03-05 1:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 0:02 What's cooking in git.git (Mar 2010, #01; Wed, 03) Junio C Hamano
2010-03-04 0:36 ` Adam Simpkins
2010-03-04 8:26 ` Björn Gustavsson
2010-03-04 18:26 ` Junio C Hamano
2010-03-04 12:09 ` Tay Ray Chuan
2010-03-04 18:26 ` Junio C Hamano
2010-03-04 21:42 ` Junio C Hamano
2010-03-05 0:49 ` Junio C Hamano
2010-03-05 16:25 ` git reset --keep (Re: What's cooking in git.git (Mar 2010, #01; Wed, 03)) Jonathan Nieder
2010-03-05 21:08 ` Christian Couder
2010-03-05 17:32 ` What's cooking in git.git (Mar 2010, #01; Wed, 03) Christian Couder
2010-03-04 22:21 ` Thomas Rast
2010-03-05 1:30 ` Mark Lodato
2010-03-05 1:32 ` Mark Lodato [this message]
2010-03-05 3:23 ` Junio C Hamano
2010-03-06 0:39 ` [PATCH] Add tests for git format-patch --to and format.to config option Miklos Vajna
2010-03-06 2:21 ` Junio C Hamano
2010-03-06 21:06 ` [PATCH] format-patch --to: overwrite format.to contents, don't append it Miklos Vajna
2010-03-07 0:06 ` [PATCH] Add tests for git format-patch --to and format.to config option Stephen Boyd
2010-03-07 1:20 ` Miklos Vajna
2010-03-07 3:42 ` Junio C Hamano
2010-03-07 9:43 ` Stephen Boyd
2010-03-07 18:38 ` Junio C Hamano
2010-03-07 21:33 ` [PATCH 0/4] format-patch and send-email ignoring config settings Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 0/3] " Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 1/3] format-patch: use a string_list for headers Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 2/3] format-patch: add --no-cc, --no-to, and --no-add-headers Stephen Boyd
2010-03-07 22:46 ` [PATCHv2 3/3] send-email: add --no-cc, --no-to, and --no-bcc Stephen Boyd
2010-03-09 2:44 ` [PATCH 0/4] format-patch and send-email ignoring config settings Junio C Hamano
2010-03-07 21:33 ` [PATCH 1/4] send-email: actually add bcc headers Stephen Boyd
2010-03-07 21:53 ` Stephen Boyd
2010-03-07 21:33 ` [PATCH 2/4] format-patch: use a string_list for headers Stephen Boyd
2010-03-07 21:44 ` Erik Faye-Lund
2010-03-07 21:54 ` Stephen Boyd
2010-03-07 22:13 ` Johannes Schindelin
2010-03-07 21:33 ` [PATCH 3/4] format-patch: add --no-cc, --no-to, and --no-add-headers Stephen Boyd
2010-03-07 21:33 ` [PATCH 4/4] send-email: add --no-cc, --no-to, and --no-bcc Stephen Boyd
2010-03-10 3:53 ` [PATCH] Add tests for git format-patch --to and format.to config option Steven Drake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca433831003041732k69c7cadcuf8f7feaabf3e372f@mail.gmail.com \
--to=lodatom@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mfwitten@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).