Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository

[Junio C Hamano <gitster@pobox.com>]

David Aguilar <davvid@gmail.com> writes:

> On Fri, Jan 15, 2010 at 08:15:49PM -0800, Junio C Hamano wrote:
>
>> Realistically, this most often is used when grepping in the log, e.g.
>> 
>>     git log --all-match --author=peff --grep=test
>> 
>> I actually wish "log" to somehow default to --all-match mode at least when
>> using the --author option.  "Change by Jeff, or about test by anybody" is
>> rarely what I would want to look for.
>
> Kinda like this?

Not quite.  What I really want is

    git log --author=davvid --grep=difftool --grep=mergetool

to find all commits by you that is about (either diff or mergetool).  I
think your patch will limit the search only to your patch that talks about
both of these two tools (not necessarily on the same line, but in the same
commit).

The extended "grep" expression parser by default creates a list of OR'ed
terms.  What --all-match does is to make this top-level chain to mean "all
of these must trigger somewhere in the whole _document_ (not an individual
line), for the document to be considered a hit" for the purpose of "grep -l",
and when used with "log" family, --author/--committer/--grep are used to
limit the output to commits "grep -l" would say "yes, this document has
matched".

Currently,

    git log --author=davvid --grep=difftool --grep=mergetool

will parse to a list of three terms:

    GREP_PATTERN_HEAD("^author .*davvid")
    GREP_PATTERN_BODY("difftool")
    GREP_PATTERN_BODY("mergetool")

And giving --all-match will require all of these OR'ed terms to appear in
the commit object.

My dream one will probably has to make a list of two terms as its parse
tree instead, like this:

    GREP_PATTERN_HEAD("^author .*davvid")
    GREP_NODE_OR(
        GREP_PATTERN_BODY("difftool")
        GREP_PATTERN_BODY("mergetool")
    )           

and then run it with --all-match semantics.  The top-level consists of two
terms, and they both must hit, but the second term is an OR'ed one.

It is unclear how we would want to throw the committer in the mix.  If we
make this parse tree:

    GREP_PATTERN_HEAD("^author .*davvid")
    GREP_PATTERN_HEAD("^committer .*gitster")
    GREP_NODE_OR(
        GREP_PATTERN_BODY("difftool")
        GREP_PATTERN_BODY("mergetool")
    )           

we would be looking for your patch about either diff or mergetool _and_
it has to be committed by me.  On the other hand, if we do this:

    GREP_NODE_OR(
        GREP_PATTERN_HEAD("^author .*davvid")
        GREP_PATTERN_HEAD("^committer .*gitster")
    )
    GREP_NODE_OR(
        GREP_PATTERN_BODY("difftool")
        GREP_PATTERN_BODY("mergetool")
    )           

we would be looking for a patch about (either diff or mergetool) _and_
(either committed by me or written by you).

I think the former makes more sense in _our_ project (because there are
very few committers), but in the context of other projects, e.g. the Linux
kernel, you may want to give "Linus" to both --author and --committer to
track what he did (either as an author to some other subsystem, or as the
top-level integrator for the entire system), and for such a use case, the
latter would make more sense.

Unfortunately, the parsing of --grep/--author/--committer options to the
log family is quite limited (you cannot give --and, --or and --not, for
example), and it would be hard to express these distinction.