Re: Supporting "-v" option for git-log

From: Jeff King <peff@peff.net>
Date: May 25, 2011, 13:29 UTC
Message-ID: <20110525132816.GA6709@sigill.intra.peff.net>
In-Reply-To: <BANLkTikT4s+Twfip2g7Zo-XcML1Wbd3qBg@mail.gmail.com>

On Wed, May 25, 2011 at 02:28:12PM +0300, Elazar Leibovich wrote:

Show 7 quoted lines

> On Wed, May 25, 2011 at 2:21 PM, Tim Mazid <timmazid@hotmail.com> wrote:
> >
> > Well, personally, I've never used the --grep option. I pipe it through
> > grep, where I can supply options such as -v.
> 
> But then you must use single-line commits output. Which is
> inconvenient if you want to read all the commit message.

You can use perl to consider records larger than a single line, like:

  git log -z | perl -ln0e 'print unless /your pattern/'

But of course that is somewhat inconvenient to type, and is somewhat slower than the internal grep.

Show 5 quoted lines

> Now that I think of it, we already have the '--not' option for
> revision specifiers. Why won't we use it for grep patterns? That way
> -v will not be overloaded (it usually means verbose). For example
> 
>     git log --all --not --grep A --grep B

The problem is that "--not" already has a meaning, and the scope of that meaning is different than what you propose. That is, in this command:

  git log a --not b c

The "--not" applies to both "b" and "c". So you are changing the meaning of the existing:

  git log a --not --grep b c

(which now means "grep for b, but do not include commits in c"). And even if we wanted to do that, there is a parsing ambiguity. Does the "--not" apply _just_ to the grep, or does it also include "not c"?

Which is a shame, because we already have all of the code for "--and", "--or", and "--not" in git-grep. It is just a syntactic conflict. I think you could get away with "--grep-and", "--grep-or", and "--grep-not". They are obviously less nice to type, but there would be not conflict.

-Peff