On Tue, Apr 11, 2017 at 12:23 PM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Apr 08, 2017 at 01:24:59PM +0000, Ævar Arnfjörð Bjarmason wrote: > >> Add exhaustive tests for how the different grep.patternType options & >> the corresponding command-line options affect git-log. >> >> Before this change it was possible to patch revision.c so that the >> --basic-regexp option was synonymous with --extended-regexp, and >> --perl-regexp wasn't recognized at all, and still have 100% of the >> test suite pass. > > I thought we _did_ have good coerage here, but I think it is only for > grep (via t7810). It makes sense to cover this for "log", too. > >> The patterns being passed to fixed/basic/extended/PCRE are carefully >> crafted to return the wrong thing if the grep engine were to pick any >> other matching method than the one it's told to use. > > This can be tricky since POSIX allows implementations to add arbitrary > extensions for otherwise invalid syntax. For POSIX basic v.s. extended I'm relying on (|) not being metacharacters in basic but metachars needing quoting in extended. I very much doubt any regex implementation doesn't conform to that, but maybe some crazy implementation does... > See my recent 7675c7bd0 (t7810: avoid assumption about invalid regex > syntax, 2017-01-11). In particular: > >> + if test_have_prereq LIBPCRE >> + then >> + git -c grep.patternType=perl log --pretty=tformat:%s \ >> + --grep="\((?=1)" >actual.perl >> + fi && > > I'd have to double-check POSIX, but I suspect that it may allow (?=1) to > work in an ERE (since it's otherwise bogus to have "?" without a prior > element to match). Distinguishing PCRE from the rest is much easier, I'll add some more obscure PCRE feature to that which definitely doesn't exist in any POSIX rx library, e.g. (*COMMIT) or something.