Re: Supporting "-v" option for git-log
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- May 25, 2011, 13:53 UTC
- Message-ID
- <m3boyqzy3f.fsf@localhost.localdomain>
- In-Reply-To
- <20110525132816.GA6709@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, May 25, 2011 at 02:28:12PM +0300, Elazar Leibovich wrote:
[...]
Show 25 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.
Hmmm... perhaps short -! could be alias for --grep-not (it is the only that needs to be changed to avoid conflict, as there are no --or and --and for rev-list).
-- Jakub Narebski Poland ShadeHawk on #git