Re: [PATCH] git-grep: --and to combine patterns with and instead of or

So here is my proposal how extended expressions would work:

extended expressions have three operators:
    AND, OR (binary), NOT (unary)
extended expressions do not need an extra option. They will be usable
by adding operators between the expressions; a default operator is
used if no operator is specified. The default operator is by default
OR because currently multiple patterns are combined by OR.

OR and AND have precedence, so there are two possibilities, I'd take
the first one.
1. OR, AND:
    This will make it easier to read because OR can be skipped:
      pat1 pat2 AND pat3 pat4
    = pat1 OR pat2 AND pat3 OR pat4
    = (pat1 OR pat2) AND (pat3 OR pat4)
2. AND, OR:
    This is a bit more logic if you think of AND as * and OR as +.

Parenthesis may be used to explicitly override the default precedence.

With this setup we can add an option -FOO (I don't now how to call it,
it is the --and from the patch) which changes the default operator and
the precedence.  With -FOO you'd get AND as default operator and
precedence AND, OR.  Without this option it was easy to write the
formula in a conjungtive form (conjunction of disjunctions), now it is
easy to write a disjunctive form (disjunction of conjunctions):
  pat1 pat2 OR pat3 pat4
= pat1 AND pat2 OR pat3 AND pat4
= (pat1 AND pat2) OR (pat3 AND pat4)

With all this as plan for extended expressions we may also introduce -FOO now with exactly the behaviour of --and in my patch because currently no explicit operators and parenthesis are allowed, so only the default operator may be used and -FOO would change the default operator.

A short example: (pat1 AND pat2 AND pat3) OR pat4 could be written as -FOO pat1 pat2 pat3 OR pat4 which is imho quite readable.

So the next problem are names for the options. We would need
 - AND: between patterns
 - OR:  between patterns
 - NOT: before a pattern
 - FOO: change default operator and precedence
Unfortunately -o, -a, -n are taken and I think the options should be
unique even though they are only allowed at certain positions of the
argument list. I'll think about it a bit, perhaps someone else has a
good idea. FOO should not be named --and imo but I don't have any idea
for a good name atm.