Ævar Arnfjörð Bjarmason <ava...@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. > + 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? > + git -c grep.patternType=perl log --pretty=tformat:%s \ > + --grep="[\d]\|" >actual.perl && > + test_cmp expect.perl actual.perl > + fi &&
