Jeff King <peff@xxxxxxxx> writes: > The problem is that "--not" already has a meaning, and the scope of that > meaning is different than what you propose. That is, in this command: > > git log a --not b c > > The "--not" applies to both "b" and "c". So you are changing the meaning > of the existing: > > git log a --not --grep b c > > (which now means "grep for b, but do not include commits in c"). And > even if we wanted to do that, there is a parsing ambiguity. Does the > "--not" apply _just_ to the grep, or does it also include "not c"? > > Which is a shame, because we already have all of the code for "--and", > "--or", and "--not" in git-grep. True, that has always been an accepted limitation. You could add --grep="-e A --and --not -e B --all-match", split_cmdline() and then give the result to append_grep_pattern(), or something like that, but I do not think it is worth doing. -- To unsubscribe from this list: 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