Jakub Narebski wrote: > I think --near _has_ to be non-symmetric binary operator, i.e. first > argument specifies line to be found, second argument has to be in context > for first line if it is found. > > So the above expression would be written as: > > -e foo --near \( A --or B \) Why is that? -e foo --and --near \( -e A -- or -e B \) would mean lines containing foo and either A or B in the context and -e foo --or --near \( -e A -- or -e B \) would mean lines containing foo or having A or B in the context. > BTW. we can make -e equivalent to --or, and empty (default) operator to > --and, but of course you have to delimit expression from files, i.e. either > > git grep A B C D -- files This is incompatible with the current implementation. 'git grep A B C D -- files' means A is the pattern, B, C, D are revisions and files is the pathspec. > or > > git grep -e \( A B C D \) files > > which would be equivalent to > > git grep A --and B --and C --and D files I think this could probably be used. But I think having two different implicit operators depending on the context is too confusing. - : 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