# Supporting "-v" option for git-log 14 messages from 2011-05-25 to 2011-05-25. Participants: Elazar Leibovich, Tim Mazid, Jeff King, Jakub Narebski, Junio C Hamano. Thread: https://gitlist.dev/t/27451 ## Elazar Leibovich, 2011-05-25 09:40 Subject: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/BANLkTik70gu0NUzUEnGNWHQr8CfbdPVe5g%40mail.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? [*] 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 ``` ## Tim Mazid, 2011-05-25 11:05 Subject: RE: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/SNT124-W39164C74A457129811245DC4740%40phx.gbl In-Reply-To: ``` > 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 ``` ## Elazar Leibovich, 2011-05-25 11:14 Subject: Re: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/BANLkTi%3Dv8j%3DVdBNgThRTFXk%2BYbPFOFvzwQ%40mail.gmail.com In-Reply-To: ``` On Wed, May 25, 2011 at 2:05 PM, Tim Mazid 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== 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. ``` ## Tim Mazid, 2011-05-25 11:21 Subject: RE: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/SNT124-W5207D5461CD80509763B79C4740%40phx.gbl In-Reply-To: ``` > 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 ``` ## Tim Mazid, 2011-05-25 11:24 Subject: RE: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/SNT124-W631EA986B78300D93BF669C4740%40phx.gbl In-Reply-To: ``` > 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 ``` ## Elazar Leibovich, 2011-05-25 11:28 Subject: Re: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/BANLkTikT4s%2BTwfip2g7Zo-XcML1Wbd3qBg%40mail.gmail.com In-Reply-To: ``` 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. > 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%'". ``` ## Tim Mazid, 2011-05-25 11:35 Subject: RE: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/SNT124-W15FA6D1CACA43B253810FAC4740%40phx.gbl In-Reply-To: ``` > 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 ``` ## Elazar Leibovich, 2011-05-25 11:40 Subject: Re: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/BANLkTimWymFNC7hP%3DX2w0RMwdLPjGC07Aw%40mail.gmail.com In-Reply-To: ``` On Wed, May 25, 2011 at 2:35 PM, Tim Mazid 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. ``` ## Jeff King, 2011-05-25 13:29 Subject: Re: Supporting "-v" option for git-log Message-ID: <20110525132816.GA6709@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110525132816.GA6709%40sigill.intra.peff.net In-Reply-To: ``` On Wed, May 25, 2011 at 02:28:12PM +0300, Elazar Leibovich wrote: > 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. 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 ``` ## Jakub Narebski, 2011-05-25 13:53 Subject: Re: Supporting "-v" option for git-log Message-ID: URL: https://gitlist.dev/e/m3boyqzy3f.fsf%40localhost.localdomain In-Reply-To: <20110525132816.GA6709@sigill.intra.peff.net> ``` Jeff King 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 ``` ## Jeff King, 2011-05-25 15:11 Subject: Re: Supporting "-v" option for git-log Message-ID: <20110525151115.GB8795@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110525151115.GB8795%40sigill.intra.peff.net In-Reply-To: ``` 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 ``` ## Jakub Narebski, 2011-05-25 16:38 Subject: Re: Supporting "-v" option for git-log Message-ID: <201105251838.59548.jnareb@gmail.com> URL: https://gitlist.dev/e/201105251838.59548.jnareb%40gmail.com In-Reply-To: <20110525151115.GB8795@sigill.intra.peff.net> ``` 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 ``` ## Junio C Hamano, 2011-05-25 17:32 Subject: Re: Supporting "-v" option for git-log Message-ID: <7vlixu4reu.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlixu4reu.fsf%40alter.siamese.dyndns.org In-Reply-To: <20110525132816.GA6709@sigill.intra.peff.net> ``` Jeff King 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. ``` ## Jeff King, 2011-05-25 20:01 Subject: Re: Supporting "-v" option for git-log Message-ID: <20110525200136.GD27260@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110525200136.GD27260%40sigill.intra.peff.net In-Reply-To: <7vlixu4reu.fsf@alter.siamese.dyndns.org> ``` 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 ```