From: Junio C Hamano Date: Mon, 18 Jan 2010 06:30:19 GMT Subject: Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository Message-ID: <7vk4vgsz5w.fsf@alter.siamese.dyndns.org> In-Reply-To: <20100118055703.GA17879@coredump.intra.peff.net> Jeff King writes: > 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 ... That is fundamentally wrong. Remember, "grep" works on two levels: a line matches or does not match the given set of patterns (rather, the expression given), and matched lines are shown. A file as a whole is considered to have matched if one or more lines produced a match, or under the --all-match option, only when all of the top-level ORed terms in the expression have fired for some lines in it. And --not and --and are both elements of grep expression that determines if the expression matches "a single line". --author=me --and --grep=foo would ask: does the "^author " line in the header have "me" _and_ also string "foo" on it at the same time? IOW, most of the "logical" stuff (including the precedence binding parentheses) works at a line level. --all-match is currently the only thing that affects "grep -l" (and "will the commit get shown") behaviour by collecting hits from the whole buffer.