Web lists-archives.com

Re: [PATCH 05/12] log: add exhaustive tests for pattern style options & config

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.