> Date: Wed, 25 May 2011 14:28:12 +0300 > From: elazarl@xxxxxxxxx > On Wed, May 25, 2011 at 2:21 PM, Tim Mazid wrote: > > > > Well, personally, I've never used the --grep option. I pipe it through > > grep, where I can supply options such as -v. > > But then you must use single-line commits output. Which is > inconvenient if you want to read all the commit message. That is a good point. > > As for the syntax, that seems like a good idea on the surface, but > > how would you go about supporting other grep options? Such as > > "-i"? > > Now that I think of it, we already have the '--not' option for > revision specifiers. Why won't we use it for grep patterns? That way > -v will not be overloaded (it usually means verbose). For example > > git log --all --not --grep A --grep B > > Would mean find all commits without A and with B, in SQL "SELECT * > FROM COMMITS WHERE message NOT LIKE '%A%' AND message LIKE '%B%'". But how do you know which "--grep" the "--not" applies to? Does it have to go directly before the "--grep" option? Can it be a few options before as long is it's still before? If you want to find commits not matching two patterns, do you have to do "--not --grep A --not --grep B"? I can see this as being a possible source of confusion; people doing "--not grep A --grep B" and expecting it to mean NOT A AND NOT B. Tim. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- 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