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. 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). -Peff