> This extends the behaviour of git-grep when multiple -e options
> are given. So far, we allowed multiple -e to behave just like
> regular grep with multiple -e, i.e. the patterns are OR'ed
> together.
>
> With this change, you can also have multiple patterns AND'ed
> together, or form boolean expressions, like this (the
> parentheses are quoted from the shell in this example):
>
> $ git grep -e _PATTERN --and \( -e atom -e token \)
This looks really nice. So for a few trivial tests it did not fail :)
I noticed an unrelated bug. The context separators ("--") are missing
between matches in different files:
$ git-grep -e foobar -A 1 (this uses external grep)
Documentation/git-diff-tree.txt:I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
Documentation/git-diff-tree.txt-so it can be used to name subdirectories.
--
git-send-email.perl:#$initial_reply_to = ''; #<20050203173208.GA23964@xxxxxxxxxx>';
git-send-email.perl-
--
[..]
$ git-grep -e foobar -A 1 master (this is internal grep)
master:Documentation/git-diff-tree.txt:I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h`
master:Documentation/git-diff-tree.txt-so it can be used to name subdirectories.
master:git-send-email.perl:#$initial_reply_to = ''; #<20050203173208.GA23964@xxxxxxxxxx>';
master:git-send-email.perl-
[..]
I think this cannot be fixed in the loop in builtin-grep.c:grep_cache
because after the last hit there should be no separator but it is not
known if a grep_sha1/grep_file will match and produce output. So I
think there has to be a variable passed down which tells those
functions to print the separator before any other output.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html