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

Ævar Arnfjörð Bjarmason  [off-list ref] writes:

s/not and//; I think.

Thanks.

Makes sense.

OK.  BRE would match because the other side of "\|" is empty to
match anything?

On Mon, May 15, 2017 at 6:57 AM, Junio C Hamano [off-list ref] wrote:

Ævar Arnfjörð Bjarmason  [off-list ref] writes:

quoted

+     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.

quoted

+     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.

quoted

+             # 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.

quoted

+             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)'

quoted

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