Supporting "-v" option for git-log

Supporting "-v" option for git-log

[Elazar Leibovich]

I want to use git log to show all commits that do not match a given
pattern. I know I can use the following to show all commits that do
match a pattern, similar to the "grep -v" command line option:

    git log -v --grep=<pattern> # results all commits that do NOT match pattern

Is there a way invert the sense of matching?

If not, is it OK to submit a patch? Anything to consider for this patch?


[*] x-post from here
http://stackoverflow.com/questions/5602204/how-to-invert-git-log-grep-pattern-or-how-to-show-git-logs-that-dont-match

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

[Tim Mazid]

> Date: Wed, 25 May 2011 12:40:48 +0300
> From: elazarl@gmail.com
>
> I want to use git log to show all commits that do not match a given
> pattern. I know I can use the following to show all commits that do
> match a pattern, similar to the "grep -v" command line option:
>
> git log -v --grep= # results all commits that do NOT match pattern
>
> Is there a way invert the sense of matching?
>
> If not, is it OK to submit a patch? Anything to consider for this patch?

I'm confused; do you want to find all the commits that do not match a
pattern? Because you seem to have achieved that. If, on the other hand,
you want the commits that DO match a pattern, then just leave out the
"-v" option.

What exactly are you trying to achieve?


Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

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

[Elazar Leibovich]

On Wed, May 25, 2011 at 2:05 PM, Tim Mazid <timmazid@hotmail.com> wrote:
>
>> Date: Wed, 25 May 2011 12:40:48 +0300
>> From: elazarl@gmail.com
>> git log -v --grep= # results all commits that do NOT match pattern
>>
>> Is there a way invert the sense of matching?
>>
> I'm confused; do you want to find all the commits that do not match a
> pattern? Because you seem to have achieved that. If, on the other hand,
> you want the commits that DO match a pattern, then just leave out the
> "-v" option.
>
> What exactly are you trying to achieve?

Oops, let me be 100% clear about that, "git log -v
--grep==<pattern_not_to_match" is NOT WORKING currently. I just
presented a possible syntax.

$ git --version
git version 1.7.4.msysgit.0
$ git log -v --grep=Normalized
commit 88c7a82aaf240ed130c64c455c294e7af04d30f8
Author: Elazar <elazarl@gmail.com>
Date:   Mon May 16 10:40:21 2011 +0300

    Normalized Makfile so that it'll work by default. Include Makefile

see, it ignores the "-v", and include only commits with "Normalized" -
the ones I don't want to see.

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

[Tim Mazid]

> From: elazarl@gmail.com
> Oops, let me be 100% clear about that, "git log -v
> --grep==> presented a possible syntax.
>
> $ git --version
> git version 1.7.4.msysgit.0
> $ git log -v --grep=Normalized
> commit 88c7a82aaf240ed130c64c455c294e7af04d30f8
> Author: Elazar 
> Date: Mon May 16 10:40:21 2011 +0300
>
> Normalized Makfile so that it'll work by default. Include Makefile
>
> see, it ignores the "-v", and include only commits with "Normalized" -
> the ones I don't want to see.

Ah, I see; my apologies.

Well, personally, I've never used the --grep option. I pipe it through
grep, where I can supply options such as -v. However, if the --grep
option already exists, then it does make sense to allow users to use
options they would normally be able to with grep.

As for the syntax, that seems like a good idea on the surface, but
how would you go about supporting other grep options? Such as
"-i"?


Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

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

[Tim Mazid]

> From: timmazid@hotmail.com
> > From: elazarl@gmail.com
> > Oops, let me be 100% clear about that, "git log -v
> > --grep==> presented a possible syntax.
> >
> > $ git --version
> > git version 1.7.4.msysgit.0
> > $ git log -v --grep=Normalized
> > commit 88c7a82aaf240ed130c64c455c294e7af04d30f8
> > Author: Elazar
> > Date: Mon May 16 10:40:21 2011 +0300
> >
> > Normalized Makfile so that it'll work by default. Include Makefile
> >
> > see, it ignores the "-v", and include only commits with "Normalized" -
> > the ones I don't want to see.
>
> Ah, I see; my apologies.
>
> Well, personally, I've never used the --grep option. I pipe it through
> grep, where I can supply options such as -v. However, if the --grep
> option already exists, then it does make sense to allow users to use
> options they would normally be able to with grep.
>
> As for the syntax, that seems like a good idea on the surface, but
> how would you go about supporting other grep options? Such as
> "-i"?

Woops; my bad; "-i" is already supported. But the point still stands...
I think?

Should there be a seperate "--grep-options" option for "git log" to
pass options onto grep?

 Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org    - against proprietary attachments
 		 	   		  

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

[Elazar Leibovich]

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.

> However, if the --grep
> option already exists, then it does make sense to allow users to use
> options they would normally be able to with grep.
>
> As for the syntax, that seems like a good idea on the surface, but
> how would you go about supporting other grep options? Such as
> "-i"?

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

Would mean find all commits without A and with B, in SQL "SELECT *
FROM COMMITS WHERE message NOT LIKE '%A%'  AND message LIKE '%B%'".

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

[Tim Mazid]

> Date: Wed, 25 May 2011 14:28:12 +0300
> From: elazarl@gmail.com
> On Wed, May 25, 2011 at 2:21 PM, Tim Mazid  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.

That is a good point.


> > As for the syntax, that seems like a good idea on the surface, but
> > how would you go about supporting other grep options? Such as
> > "-i"?
>
> 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
>
> Would mean find all commits without A and with B, in SQL "SELECT *
> FROM COMMITS WHERE message NOT LIKE '%A%' AND message LIKE '%B%'".

But how do you know which "--grep" the "--not" applies to? Does it have 
to go directly before the "--grep" option? Can it be a few options before
as long is it's still before? If you want to find commits not matching two
patterns, do you have to do "--not --grep A --not --grep B"?

I can see this as being a possible source of confusion; people doing
"--not grep A --grep B" and expecting it to mean NOT A AND NOT B.


Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

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

[Elazar Leibovich]

On Wed, May 25, 2011 at 2:35 PM, Tim Mazid <timmazid@hotmail.com> wrote:
>
>> git log --all --not --grep A --grep B
>>
>> Would mean find all commits without A and with B, in SQL "SELECT *
>> FROM COMMITS WHERE message NOT LIKE '%A%' AND message LIKE '%B%'".
>
> But how do you know which "--grep" the "--not" applies to? Does it have
> to go directly before the "--grep" option?

Exactly, just like the ! operator in C.

> Can it be a few options before
> as long is it's still before?

No, only directly before the --grep, like the ! operator.

> If you want to find commits not matching two
> patterns, do you have to do "--not --grep A --not --grep B"?

Yes, we can add a --negate-all option if you think it's usefull.

>
> I can see this as being a possible source of confusion; people doing
> "--not grep A --grep B" and expecting it to mean NOT A AND NOT B.

You can add another option --negate which negates everything. But this
is a price to pay for being extra expressive.

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

[Jeff King]

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

> 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.

> 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

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

[Jakub Narebski]

Jeff King <peff@peff.net> writes:
> On Wed, May 25, 2011 at 02:28:12PM +0300, Elazar Leibovich wrote:

[...]
> > 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

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

[Jeff King]

On Wed, May 25, 2011 at 06:53:31AM -0700, Jakub Narebski wrote:

> > 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).

Ick. I really hate using shell metacharacters that need quoting
(especially "!", which even gets expanded inside double-quotes). But as
long as it's an alias, I guess people who care can use --grep-not.

We could use unadorned "--or" and "--and", though we should perhaps stop
and think whether taking those basic operators will block future use
that matches the current "--not" more.

Right now, "git log a b" is what I would expect "git log a --or b" to
do. I guess "git log a --and b" would be "git log $(git merge-base a
b)". So maybe it is not worth reserving them for the future, since what
they would (probably) accomplish is easy to do now.

-Peff

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

[Jakub Narebski]

Dnia środa 25. maja 2011 17:11, Jeff King napisał:
> On Wed, May 25, 2011 at 06:53:31AM -0700, Jakub Narebski wrote:
> 
> > > 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).
> 
> Ick. I really hate using shell metacharacters that need quoting
> (especially "!", which even gets expanded inside double-quotes). But as
> long as it's an alias, I guess people who care can use --grep-not.

Yeah, I know.  Nevertheless '!' is natural to mean 'not', 
and `-\!` is still shorter than `--grep-not`.
 
-- 
Jakub Narebski
Poland

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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.

True, that has always been an accepted limitation.

You could add --grep="-e A --and --not -e B --all-match", split_cmdline()
and then give the result to append_grep_pattern(), or something like that,
but I do not think it is worth doing.

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

[Jeff King]

On Wed, May 25, 2011 at 10:32:41AM -0700, Junio C Hamano wrote:

> > (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.
> 
> True, that has always been an accepted limitation.
> 
> You could add --grep="-e A --and --not -e B --all-match", split_cmdline()
> and then give the result to append_grep_pattern(), or something like that,
> but I do not think it is worth doing.

Besides being ambiguous with current usage (e.g., grepping for something
starting with "-e"), I do not long for the quoting nightmare of:

  git log --grep="-e 'something with spaces'
      --and --not -e 'something with \"double quotes\"'
      --and --not -e 'something with '\\''single quotes'\\''"

-Peff