Junio C Hamano <gitster@xxxxxxxxx> writes: > Jeff King <peff@xxxxxxxx> writes: > >> But none of that is exposed via the command-line of "git log". I think >> it would be possible to do so, but I'm not sure how tricky it would be >> (certainly one complication is that "--not" already means something else >> there, but presumably we could have "--grep-and", "--grep-not", etc). > > Perhaps the definition of "distant future" is about 8 years ;-) > > https://lore.kernel.org/git/7vr4q45y65.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ Having said that, I do not think our underlying grep machinery is equipped to answer "find every commit whose log message has X but not Y", even if we exposed the interface that is equivalent to that of "git grep" to "git log". There are two levels of boolean combination involved in running our "grep" machinery. The lower level is used to determine if each line matches the criteria. The main consumer of the "grep" machinery is of course "git grep" and because it is line oriented, we have quite a rich set of operations and combinations to say things like "if a line has X and Y on it in any order, but not Z on it, then the line is a match." That is what "--not", "--and", "--or" (not exposed to the "git log" interface) express and we even take "(" and ")" for grouping, e.g. "( X --or Y ) --and --not Z". Another level of combination is to determine if the entire document matches. It often happens that you want to find a document with both X and Y in it, and "grep -e X --and -e Y" is *NOT* a way to do so---the "--and" is a line-level combinator and tells the machinery to find lines that have both X and Y on them. We have a fairly ad-hoc single mechanism for boolean combination at this level and that is the "--all-match" option, which says "Look at the boolean expression you used to find each matching line, and separate them at the OR operator at the top level. Now, apply the matching logic to all lines in a document and see if _all_ the clauses joined by the top-level OR operators matched at least once. If yes, then the document matches." That is how "git grep --all-match -e X -e Y" finds documents that refer to both X and Y but not necessarily on the same line. There is not much room for the line-level "--not" operator to participate in this picture. "git grep -e X --not -e Y" would mean "find lines that has X, or that does not have Y", so as long as a document has one line with X on it and one line (which can be but does not have to be the same line) that does not have Y on it, the variant of that search with "--all-match" in it would say "yup the doc matches". But that is definitely not what the user who wants to say "if a doc has X in it, I want to see it, but I do not want to see it if it also has Y" wants to see.
