Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository
- From
Jeff King <peff@peff.net>
- Date
- Jan 18, 2010, 05:57 UTC
- Message-ID
- <20100118055703.GA17879@coredump.intra.peff.net>
- In-Reply-To
- <7v3a24ukku.fsf@alter.siamese.dyndns.org>
On Sun, Jan 17, 2010 at 08:02:25PM -0800, Junio C Hamano wrote:
Show 23 quoted lines
> Subject: "log --author=me --grep=it" should find intersection, not union
>
> Historically, any grep filter in "git log" family of commands were taken
> as restricting to commits with any of the words in the commit log message.
> However, the user almost always want to find commits "done by this person
> on that topic". With "--all-match" option, a series of grep patterns can
> be turned into a requirement that all of them must produce a match, but
> that makes it impossible to ask for "done by me, on either this or that"
> with:
>
> log --author=me --grep=this --grep=that
>
> because it will require both "this" and "that" to appear.
>
> Change the "header" parser of grep library to treat the headers specially.
> When parsing the above, behave as if it was specified like this on the
> command line:
>
> --all-match --author=me '(' --grep=this --grep=that ')'
>
> Even though the "log" command line parser doesn't give direct access to
> the extended grep syntax to group terms with parentheses, this change will
> cover the majority of the case the users would want.Hmm. I like the new behavior. The implementation feels a little hack-ish, like we should really be supporting full-on:
git log --author=me --and --grep=foo
That gets a little weird, though. We already have "--not" for ref limiting, so clearly there is some conflict over exactly what logical operators would be operating on. I guess we could use context to see that the adjacent arguments were grep-related.
So perhaps, as you say, this is enough as it covers the usual case.
-Peff