Re: [PATCH v2 04/29] log: add exhaustive tests for pattern style options & config

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, May 15, 2017 at 6:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> +     echo 2e >expect &&
>> +     # In PCRE \d in [\d] is like saying "0-9", and matches the 2
>> +     # in 2e...
>> +     git -C num_commits log -1 --pretty="tformat:%s" -F -E --perl-regexp --grep="[\d]" >actual &&
>> +     test_cmp expect actual &&
>> +     echo 1d >expect &&
>> +     # ...in POSIX basic & extended it is the same as [d],
>> +     # i.e. "d", which matches 1d, but not and does not match 2e.
>
> s/not and//; I think.

Will fix.

>> +     git -C num_commits log -1 --pretty="tformat:%s" -F -E --grep="[\d]" >actual &&
>>       test_cmp expect actual
>>  '
>>
>> @@ -280,6 +301,77 @@ test_expect_success 'log with grep.patternType configuration and command line' '
>>       test_cmp expect actual
>>  '
>>
>> +test_expect_success 'log with various grep.patternType configurations & command-lines' '
>> +     git init pattern-type &&
>> +     (
>> +             cd pattern-type &&
>> +             test_commit 1 file A &&
>> +
>> +             # The tagname is overridden here because creating a
>> +             # tag called "(1|2)" as test_commit would otherwise
>> +             # implicitly do would fail on e.g. MINGW.
>
> Thanks.
>
>> +             # POSIX extended needs to have | escaped to match it
>> +             # literally, whereas under basic this is the same as
>> +             # (|2), i.e. it would also match "1". This test checks
>> +             # for extended by asserting that it is not matching
>> +             # what basic would match.
>> +             git -c grep.patternType=extended log --pretty=tformat:%s \
>> +                     --grep="\|2" >actual.extended &&
>
> Makes sense.
>
>> +             if test_have_prereq PCRE
>> +             then
>> +                     # Only PCRE would match [\d]\| with only
>> +                     # "(1|2)" due to [\d]. POSIX basic would match
>> +                     # both it and "1", and POSIX extended would
>> +                     # match neither.
>
> OK.  BRE would match because the other side of "\|" is empty to
> match anything?

Yes. I'll clarify this. It's not just a POSIX basic feature. The same
is true of extended and perl. E.g.:

    git grep [-E|-P] 'foo|bar'

Both match the same as:

    git grep [-E|-P] '(foo|bar)'

>> +                     git -c grep.patternType=perl log --pretty=tformat:%s \
>> +                             --grep="[\d]\|" >actual.perl &&
>> +                     test_cmp expect.perl actual.perl
>> +             fi &&
>