2012-10-15 08:25:55 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='wildmatch tests'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
t: avoid sed-based chain-linting in some expensive cases
Commit 878f988350 (t/test-lib: teach --chain-lint to detect broken
&&-chains in subshells, 2018-07-11) introduced additional chain-lint
tests which add an extra "sed" pipeline to each test we run. This has a
measurable impact on runtime. Here are timings with and without a new
environment variable (added by this patch) that lets you disable just
the additional sed-based chain-lint tests:
Benchmark #1: GIT_TEST_CHAIN_LINT_HARDER=1 make test
Time (mean ± σ): 64.202 s ± 1.030 s [User: 622.469 s, System: 301.402 s]
Range (min … max): 61.571 s … 65.662 s 10 runs
Benchmark #2: GIT_TEST_CHAIN_LINT_HARDER=0 make test
Time (mean ± σ): 57.591 s ± 0.333 s [User: 529.368 s, System: 270.618 s]
Range (min … max): 57.143 s … 58.309 s 10 runs
Summary
'GIT_TEST_CHAIN_LINT_HARDER=0 make test' ran
1.11 ± 0.02 times faster than 'GIT_TEST_CHAIN_LINT_HARDER=1 make test'
Of course those extra lint checks are doing something useful, so paying
a few extra seconds (at least on Linux) isn't so bad (though note the
CPU time; we're bounded in our parallel run here by the slowest test, so
it really is ~120s of CPU improvement).
But we can observe that there are some test scripts where they produce a
much stronger effect, and provide less value. In t0027 and t3070 we run
a very large number of small tests, all driven by a series of
functions/loops which are filling in the test bodies. There we get much
less bang for our buck in terms of bug-finding versus CPU cost.
This patch introduces a mechanism for controlling when those extra
lint checks are run, at two levels:
- a user can ask to disable or to force-enable the checks by setting
GIT_TEST_CHAIN_LINT_HARDER
- if the user hasn't specified a preference, individual scripts can
disable the checks by setting GIT_TEST_CHAIN_LINT_HARDER_DEFAULT;
scripts which don't set that get the current behavior of enabling
them.
In addition, this patch flips the default for t0027 and t3070's
mass-generated sections to disable the extra checks. Here are the timing
results for t0027:
Benchmark #1: GIT_TEST_CHAIN_LINT_HARDER=1 ./t0027-auto-crlf.sh
Time (mean ± σ): 17.078 s ± 0.848 s [User: 14.878 s, System: 7.075 s]
Range (min … max): 15.952 s … 18.421 s 10 runs
Benchmark #2: GIT_TEST_CHAIN_LINT_HARDER=0 ./t0027-auto-crlf.sh
Time (mean ± σ): 9.063 s ± 0.759 s [User: 7.890 s, System: 3.362 s]
Range (min … max): 7.747 s … 10.619 s 10 runs
Benchmark #3: ./t0027-auto-crlf.sh
Time (mean ± σ): 9.186 s ± 0.881 s [User: 7.957 s, System: 3.427 s]
Range (min … max): 7.796 s … 10.498 s 10 runs
Summary
'GIT_TEST_CHAIN_LINT_HARDER=0 ./t0027-auto-crlf.sh' ran
1.01 ± 0.13 times faster than './t0027-auto-crlf.sh'
1.88 ± 0.18 times faster than 'GIT_TEST_CHAIN_LINT_HARDER=1 ./t0027-auto-crlf.sh'
We can see that disabling the checks for the whole script buys us an
almost 2x speedup. But the new default behavior, disabling them only for
the mass-generated part, gets us most of that speedup (but still leaves
the checks on for further manual tests people might write).
As a side note, I'd caution about comparing runtimes and CPU seconds
between this timing and the earlier "make test" one. In "make test",
we're running a lot of scripts in parallel, so the CPU is throttling
down (and thus a CPU second saved here would count for more during a
parallel run; the same work takes more CPU seconds there).
We get similar results for t3070:
Benchmark #1: GIT_TEST_CHAIN_LINT_HARDER=1 ./t3070-wildmatch.sh
Time (mean ± σ): 20.054 s ± 3.967 s [User: 16.003 s, System: 8.286 s]
Range (min … max): 11.891 s … 23.671 s 10 runs
Benchmark #2: GIT_TEST_CHAIN_LINT_HARDER=0 ./t3070-wildmatch.sh
Time (mean ± σ): 12.399 s ± 2.256 s [User: 7.542 s, System: 5.342 s]
Range (min … max): 9.606 s … 15.727 s 10 runs
Benchmark #3: ./t3070-wildmatch.sh
Time (mean ± σ): 10.726 s ± 3.476 s [User: 6.790 s, System: 4.365 s]
Range (min … max): 5.444 s … 15.376 s 10 runs
Summary
'./t3070-wildmatch.sh' ran
1.16 ± 0.43 times faster than 'GIT_TEST_CHAIN_LINT_HARDER=0 ./t3070-wildmatch.sh'
1.87 ± 0.71 times faster than 'GIT_TEST_CHAIN_LINT_HARDER=1 ./t3070-wildmatch.sh'
Again, we get almost a 2x speedup disabling these. In this case, there
are no tests not covered by the script's "default to disable" behavior,
so the second two benchmarks should be the same (and while they do
differ, you can see the variance is quite high but they're within one
standard deviation).
So it seems like for these two scripts, at least, disabling the extra
checks is a reasonable tradeoff. Sadly, the overall runtime of "make
test" on my system doesn't get much faster. But that's because we're
mostly limited by the cost of the single biggest test. Here are the
top-5 tests by wall-clock time from a parallel run, before my patch:
57.9192368984222 t9001-send-email.sh
45.6329638957977 t0027-auto-crlf.sh
32.5278220176697 t3070-wildmatch.sh
22.2701289653778 t7610-mergetool.sh
20.8635759353638 t1701-racy-split-index.sh
And after:
57.1476998329163 t9001-send-email.sh
33.776211977005 t0027-auto-crlf.sh
21.3116669654846 t7610-mergetool.sh
20.7748689651489 t1701-racy-split-index.sh
19.6957249641418 t7112-reset-submodule.sh
We dropped 12s from t0027, and t3070 dropped off our list entirely at
around 16s. In both cases we're bound by t9001, but its slowness is
due to the actual tests, so we'll have to deal with it in a different
way. But this reduces overall CPU, and means that dealing with t9001 (by
improving the speed of send-email or splitting it apart) will let us
reduce our overall runtime even on multi-core machines.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-13 08:25:53 +02:00
|
|
|
# Disable expensive chain-lint tests; all of the tests in this script
|
|
|
|
# are variants of a few trivial test-tool invocations, and there are a lot of
|
|
|
|
# them.
|
|
|
|
GIT_TEST_CHAIN_LINT_HARDER_DEFAULT=0
|
|
|
|
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
should_create_test_file() {
|
|
|
|
file=$1
|
|
|
|
|
|
|
|
case $file in
|
|
|
|
# `touch .` will succeed but obviously not do what we intend
|
|
|
|
# here.
|
|
|
|
".")
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
# We cannot create a file with an empty filename.
|
|
|
|
"")
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
# The tests that are testing that e.g. foo//bar is matched by
|
|
|
|
# foo/*/bar can't be tested on filesystems since there's no
|
|
|
|
# way we're getting a double slash.
|
|
|
|
*//*)
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
# When testing the difference between foo/bar and foo/bar/ we
|
|
|
|
# can't test the latter.
|
|
|
|
*/)
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
# On Windows, \ in paths is silently converted to /, which
|
|
|
|
# would result in the "touch" below working, but the test
|
|
|
|
# itself failing. See 6fd1106aa4 ("t3700: Skip a test with
|
|
|
|
# backslashes in pathspec", 2009-03-13) for prior art and
|
|
|
|
# details.
|
|
|
|
*\\*)
|
|
|
|
if ! test_have_prereq BSLASHPSPEC
|
|
|
|
then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
# NOTE: The ;;& bash extension is not portable, so
|
|
|
|
# this test needs to be at the end of the pattern
|
|
|
|
# list.
|
|
|
|
#
|
|
|
|
# If we want to add more conditional returns we either
|
|
|
|
# need a new case statement, or turn this whole thing
|
|
|
|
# into a series of "if" tests.
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
|
|
# On Windows proper (i.e. not Cygwin) many file names which
|
|
|
|
# under Cygwin would be emulated don't work.
|
|
|
|
if test_have_prereq MINGW
|
|
|
|
then
|
|
|
|
case $file in
|
|
|
|
" ")
|
|
|
|
# Files called " " are forbidden on Windows
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
*\<*|*\>*|*:*|*\"*|*\|*|*\?*|*\**)
|
|
|
|
# Files with various special characters aren't
|
|
|
|
# allowed on Windows. Sourced from
|
|
|
|
# https://stackoverflow.com/a/31976060
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
match_with_function() {
|
|
|
|
text=$1
|
|
|
|
pattern=$2
|
|
|
|
match_expect=$3
|
|
|
|
match_function=$4
|
2012-10-15 08:25:55 +02:00
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
if test "$match_expect" = 1
|
2018-01-30 22:21:16 +01:00
|
|
|
then
|
2018-01-30 22:21:21 +01:00
|
|
|
test_expect_success "$match_function: match '$text' '$pattern'" "
|
2018-03-24 08:45:04 +01:00
|
|
|
test-tool wildmatch $match_function '$text' '$pattern'
|
2018-01-30 22:21:15 +01:00
|
|
|
"
|
2018-01-30 22:21:21 +01:00
|
|
|
elif test "$match_expect" = 0
|
2018-01-30 22:21:18 +01:00
|
|
|
then
|
2018-01-30 22:21:21 +01:00
|
|
|
test_expect_success "$match_function: no match '$text' '$pattern'" "
|
2018-03-24 08:45:04 +01:00
|
|
|
test_must_fail test-tool wildmatch $match_function '$text' '$pattern'
|
2018-01-30 22:21:15 +01:00
|
|
|
"
|
2018-01-30 22:21:18 +01:00
|
|
|
else
|
2018-01-30 22:21:21 +01:00
|
|
|
test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
|
2018-01-30 22:21:15 +01:00
|
|
|
fi
|
2018-01-30 22:21:21 +01:00
|
|
|
|
2013-05-30 12:19:10 +02:00
|
|
|
}
|
|
|
|
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match_with_ls_files() {
|
|
|
|
text=$1
|
|
|
|
pattern=$2
|
|
|
|
match_expect=$3
|
|
|
|
match_function=$4
|
|
|
|
ls_files_args=$5
|
|
|
|
|
|
|
|
match_stdout_stderr_cmp="
|
|
|
|
tr -d '\0' <actual.raw >actual &&
|
2018-07-27 19:48:11 +02:00
|
|
|
test_must_be_empty actual.err &&
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
test_cmp expect actual"
|
|
|
|
|
|
|
|
if test "$match_expect" = 'E'
|
|
|
|
then
|
|
|
|
if test -e .git/created_test_file
|
|
|
|
then
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match dies on '$pattern' '$text'" "
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
printf '%s' '$text' >expect &&
|
|
|
|
test_must_fail git$ls_files_args ls-files -z -- '$pattern'
|
|
|
|
"
|
|
|
|
else
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
fi
|
|
|
|
elif test "$match_expect" = 1
|
|
|
|
then
|
|
|
|
if test -e .git/created_test_file
|
|
|
|
then
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match '$pattern' '$text'" "
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
printf '%s' '$text' >expect &&
|
|
|
|
git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
|
|
|
|
$match_stdout_stderr_cmp
|
|
|
|
"
|
|
|
|
else
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): match skip '$pattern' '$text'" 'false'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
fi
|
|
|
|
elif test "$match_expect" = 0
|
|
|
|
then
|
|
|
|
if test -e .git/created_test_file
|
|
|
|
then
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_success EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): no match '$pattern' '$text'" "
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
>expect &&
|
|
|
|
git$ls_files_args ls-files -z -- '$pattern' >actual.raw 2>actual.err &&
|
|
|
|
$match_stdout_stderr_cmp
|
|
|
|
"
|
|
|
|
else
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_failure EXPENSIVE_ON_WINDOWS "$match_function (via ls-files): no match skip '$pattern' '$text'" 'false'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
fi
|
|
|
|
else
|
|
|
|
test_expect_success "PANIC: Test framework error. Unknown matches value $match_expect" 'false'
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
match() {
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
if test "$#" = 6
|
|
|
|
then
|
2018-03-24 08:45:04 +01:00
|
|
|
# When test-tool wildmatch and git ls-files produce the same
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
# result.
|
|
|
|
match_glob=$1
|
|
|
|
match_file_glob=$match_glob
|
|
|
|
match_iglob=$2
|
|
|
|
match_file_iglob=$match_iglob
|
|
|
|
match_pathmatch=$3
|
|
|
|
match_file_pathmatch=$match_pathmatch
|
|
|
|
match_pathmatchi=$4
|
|
|
|
match_file_pathmatchi=$match_pathmatchi
|
|
|
|
text=$5
|
|
|
|
pattern=$6
|
|
|
|
elif test "$#" = 10
|
|
|
|
then
|
|
|
|
match_glob=$1
|
|
|
|
match_iglob=$2
|
|
|
|
match_pathmatch=$3
|
|
|
|
match_pathmatchi=$4
|
|
|
|
match_file_glob=$5
|
|
|
|
match_file_iglob=$6
|
|
|
|
match_file_pathmatch=$7
|
|
|
|
match_file_pathmatchi=$8
|
|
|
|
text=$9
|
|
|
|
pattern=${10}
|
|
|
|
fi
|
|
|
|
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_success EXPENSIVE_ON_WINDOWS 'cleanup after previous file test' '
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
if test -e .git/created_test_file
|
|
|
|
then
|
|
|
|
git reset &&
|
|
|
|
git clean -df
|
|
|
|
fi
|
|
|
|
'
|
|
|
|
|
|
|
|
printf '%s' "$text" >.git/expected_test_file
|
|
|
|
|
2018-01-30 22:21:24 +01:00
|
|
|
test_expect_success EXPENSIVE_ON_WINDOWS "setup match file test for $text" '
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
file=$(cat .git/expected_test_file) &&
|
|
|
|
if should_create_test_file "$file"
|
|
|
|
then
|
|
|
|
dirs=${file%/*}
|
|
|
|
if test "$file" != "$dirs"
|
|
|
|
then
|
|
|
|
mkdir -p -- "$dirs" &&
|
|
|
|
touch -- "./$text"
|
|
|
|
else
|
|
|
|
touch -- "./$file"
|
|
|
|
fi &&
|
|
|
|
git add -A &&
|
|
|
|
printf "%s" "$file" >.git/created_test_file
|
|
|
|
elif test -e .git/created_test_file
|
|
|
|
then
|
|
|
|
rm .git/created_test_file
|
|
|
|
fi
|
|
|
|
'
|
2018-01-30 22:21:21 +01:00
|
|
|
|
2018-03-24 08:45:04 +01:00
|
|
|
# $1: Case sensitive glob match: test-tool wildmatch & ls-files
|
2018-01-30 22:21:21 +01:00
|
|
|
match_with_function "$text" "$pattern" $match_glob "wildmatch"
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match_with_ls_files "$text" "$pattern" $match_file_glob "wildmatch" " --glob-pathspecs"
|
2018-01-30 22:21:21 +01:00
|
|
|
|
2018-03-24 08:45:04 +01:00
|
|
|
# $2: Case insensitive glob match: test-tool wildmatch & ls-files
|
2018-01-30 22:21:21 +01:00
|
|
|
match_with_function "$text" "$pattern" $match_iglob "iwildmatch"
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match_with_ls_files "$text" "$pattern" $match_file_iglob "iwildmatch" " --glob-pathspecs --icase-pathspecs"
|
2018-01-30 22:21:21 +01:00
|
|
|
|
2018-03-24 08:45:04 +01:00
|
|
|
# $3: Case sensitive path match: test-tool wildmatch & ls-files
|
2018-01-30 22:21:21 +01:00
|
|
|
match_with_function "$text" "$pattern" $match_pathmatch "pathmatch"
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match_with_ls_files "$text" "$pattern" $match_file_pathmatch "pathmatch" ""
|
2018-01-30 22:21:21 +01:00
|
|
|
|
2018-03-24 08:45:04 +01:00
|
|
|
# $4: Case insensitive path match: test-tool wildmatch & ls-files
|
2018-01-30 22:21:21 +01:00
|
|
|
match_with_function "$text" "$pattern" $match_pathmatchi "ipathmatch"
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match_with_ls_files "$text" "$pattern" $match_file_pathmatchi "ipathmatch" " --icase-pathspecs"
|
2013-01-01 03:44:07 +01:00
|
|
|
}
|
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
# Basic wildmatch features
|
|
|
|
match 1 1 1 1 foo foo
|
|
|
|
match 0 0 0 0 foo bar
|
|
|
|
match 1 1 1 1 '' ""
|
|
|
|
match 1 1 1 1 foo '???'
|
|
|
|
match 0 0 0 0 foo '??'
|
|
|
|
match 1 1 1 1 foo '*'
|
|
|
|
match 1 1 1 1 foo 'f*'
|
|
|
|
match 0 0 0 0 foo '*f'
|
|
|
|
match 1 1 1 1 foo '*foo*'
|
|
|
|
match 1 1 1 1 foobar '*ob*a*r*'
|
|
|
|
match 1 1 1 1 aaaaaaabababab '*ab'
|
|
|
|
match 1 1 1 1 'foo*' 'foo\*'
|
|
|
|
match 0 0 0 0 foobar 'foo\*bar'
|
|
|
|
match 1 1 1 1 'f\oo' 'f\\oo'
|
|
|
|
match 1 1 1 1 ball '*[al]?'
|
|
|
|
match 0 0 0 0 ten '[ten]'
|
2018-10-27 10:48:23 +02:00
|
|
|
match 1 1 1 1 ten '**[!te]'
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 0 0 ten '**[!ten]'
|
|
|
|
match 1 1 1 1 ten 't[a-g]n'
|
|
|
|
match 0 0 0 0 ten 't[!a-g]n'
|
|
|
|
match 1 1 1 1 ton 't[!a-g]n'
|
|
|
|
match 1 1 1 1 ton 't[^a-g]n'
|
|
|
|
match 1 1 1 1 'a]b' 'a[]]b'
|
|
|
|
match 1 1 1 1 a-b 'a[]-]b'
|
|
|
|
match 1 1 1 1 'a]b' 'a[]-]b'
|
|
|
|
match 0 0 0 0 aab 'a[]-]b'
|
|
|
|
match 1 1 1 1 aab 'a[]a-]b'
|
|
|
|
match 1 1 1 1 ']' ']'
|
2012-10-15 08:25:55 +02:00
|
|
|
|
|
|
|
# Extended slash-matching features
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 1 1 'foo/baz/bar' 'foo*bar'
|
|
|
|
match 0 0 1 1 'foo/baz/bar' 'foo**bar'
|
2018-10-27 10:48:23 +02:00
|
|
|
match 1 1 1 1 'foobazbar' 'foo**bar'
|
2018-01-30 22:21:21 +01:00
|
|
|
match 1 1 1 1 'foo/baz/bar' 'foo/**/bar'
|
|
|
|
match 1 1 0 0 'foo/baz/bar' 'foo/**/**/bar'
|
|
|
|
match 1 1 1 1 'foo/b/a/z/bar' 'foo/**/bar'
|
|
|
|
match 1 1 1 1 'foo/b/a/z/bar' 'foo/**/**/bar'
|
|
|
|
match 1 1 0 0 'foo/bar' 'foo/**/bar'
|
|
|
|
match 1 1 0 0 'foo/bar' 'foo/**/**/bar'
|
|
|
|
match 0 0 1 1 'foo/bar' 'foo?bar'
|
|
|
|
match 0 0 1 1 'foo/bar' 'foo[/]bar'
|
|
|
|
match 0 0 1 1 'foo/bar' 'foo[^a-z]bar'
|
|
|
|
match 0 0 1 1 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
|
|
|
|
match 1 1 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
|
|
|
|
match 1 1 0 0 'foo' '**/foo'
|
|
|
|
match 1 1 1 1 'XXX/foo' '**/foo'
|
|
|
|
match 1 1 1 1 'bar/baz/foo' '**/foo'
|
|
|
|
match 0 0 1 1 'bar/baz/foo' '*/foo'
|
|
|
|
match 0 0 1 1 'foo/bar/baz' '**/bar*'
|
|
|
|
match 1 1 1 1 'deep/foo/bar/baz' '**/bar/*'
|
|
|
|
match 0 0 1 1 'deep/foo/bar/baz/' '**/bar/*'
|
|
|
|
match 1 1 1 1 'deep/foo/bar/baz/' '**/bar/**'
|
|
|
|
match 0 0 0 0 'deep/foo/bar' '**/bar/*'
|
|
|
|
match 1 1 1 1 'deep/foo/bar/' '**/bar/**'
|
|
|
|
match 0 0 1 1 'foo/bar/baz' '**/bar**'
|
|
|
|
match 1 1 1 1 'foo/bar/baz/x' '*/bar/**'
|
|
|
|
match 0 0 1 1 'deep/foo/bar/baz/x' '*/bar/**'
|
|
|
|
match 1 1 1 1 'deep/foo/bar/baz/x' '**/bar/*/*'
|
2012-10-15 08:25:55 +02:00
|
|
|
|
|
|
|
# Various additional tests
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 0 0 'acrt' 'a[c-c]st'
|
|
|
|
match 1 1 1 1 'acrt' 'a[c-c]rt'
|
|
|
|
match 0 0 0 0 ']' '[!]-]'
|
|
|
|
match 1 1 1 1 'a' '[!]-]'
|
|
|
|
match 0 0 0 0 '' '\'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match 0 0 0 0 \
|
|
|
|
1 1 1 1 '\' '\'
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 0 0 'XXX/\' '*/\'
|
|
|
|
match 1 1 1 1 'XXX/\' '*/\\'
|
|
|
|
match 1 1 1 1 'foo' 'foo'
|
|
|
|
match 1 1 1 1 '@foo' '@foo'
|
|
|
|
match 0 0 0 0 'foo' '@foo'
|
|
|
|
match 1 1 1 1 '[ab]' '\[ab]'
|
|
|
|
match 1 1 1 1 '[ab]' '[[]ab]'
|
|
|
|
match 1 1 1 1 '[ab]' '[[:]ab]'
|
|
|
|
match 0 0 0 0 '[ab]' '[[::]ab]'
|
|
|
|
match 1 1 1 1 '[ab]' '[[:digit]ab]'
|
|
|
|
match 1 1 1 1 '[ab]' '[\[:]ab]'
|
|
|
|
match 1 1 1 1 '?a?b' '\??\?b'
|
|
|
|
match 1 1 1 1 'abc' '\a\b\c'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match 0 0 0 0 \
|
|
|
|
E E E E 'foo' ''
|
2018-01-30 22:21:21 +01:00
|
|
|
match 1 1 1 1 'foo/bar/baz/to' '**/t[o]'
|
2012-10-15 08:25:55 +02:00
|
|
|
|
|
|
|
# Character class tests
|
2018-01-30 22:21:21 +01:00
|
|
|
match 1 1 1 1 'a1B' '[[:alpha:]][[:digit:]][[:upper:]]'
|
|
|
|
match 0 1 0 1 'a' '[[:digit:][:upper:][:space:]]'
|
|
|
|
match 1 1 1 1 'A' '[[:digit:][:upper:][:space:]]'
|
|
|
|
match 1 1 1 1 '1' '[[:digit:][:upper:][:space:]]'
|
|
|
|
match 0 0 0 0 '1' '[[:digit:][:upper:][:spaci:]]'
|
|
|
|
match 1 1 1 1 ' ' '[[:digit:][:upper:][:space:]]'
|
|
|
|
match 0 0 0 0 '.' '[[:digit:][:upper:][:space:]]'
|
|
|
|
match 1 1 1 1 '.' '[[:digit:][:punct:][:space:]]'
|
|
|
|
match 1 1 1 1 '5' '[[:xdigit:]]'
|
|
|
|
match 1 1 1 1 'f' '[[:xdigit:]]'
|
|
|
|
match 1 1 1 1 'D' '[[:xdigit:]]'
|
|
|
|
match 1 1 1 1 '_' '[[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:graph:][:lower:][:print:][:punct:][:space:][:upper:][:xdigit:]]'
|
|
|
|
match 1 1 1 1 '.' '[^[:alnum:][:alpha:][:blank:][:cntrl:][:digit:][:lower:][:space:][:upper:][:xdigit:]]'
|
|
|
|
match 1 1 1 1 '5' '[a-c[:digit:]x-z]'
|
|
|
|
match 1 1 1 1 'b' '[a-c[:digit:]x-z]'
|
|
|
|
match 1 1 1 1 'y' '[a-c[:digit:]x-z]'
|
|
|
|
match 0 0 0 0 'q' '[a-c[:digit:]x-z]'
|
2012-10-15 08:25:55 +02:00
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
# Additional tests, including some malformed wildmatch patterns
|
|
|
|
match 1 1 1 1 ']' '[\\-^]'
|
|
|
|
match 0 0 0 0 '[' '[\\-^]'
|
|
|
|
match 1 1 1 1 '-' '[\-_]'
|
|
|
|
match 1 1 1 1 ']' '[\]]'
|
|
|
|
match 0 0 0 0 '\]' '[\]]'
|
|
|
|
match 0 0 0 0 '\' '[\]]'
|
|
|
|
match 0 0 0 0 'ab' 'a[]b'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match 0 0 0 0 \
|
|
|
|
1 1 1 1 'a[]b' 'a[]b'
|
|
|
|
match 0 0 0 0 \
|
|
|
|
1 1 1 1 'ab[' 'ab['
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 0 0 'ab' '[!'
|
|
|
|
match 0 0 0 0 'ab' '[-'
|
|
|
|
match 1 1 1 1 '-' '[-]'
|
|
|
|
match 0 0 0 0 '-' '[a-'
|
|
|
|
match 0 0 0 0 '-' '[!a-'
|
|
|
|
match 1 1 1 1 '-' '[--A]'
|
|
|
|
match 1 1 1 1 '5' '[--A]'
|
|
|
|
match 1 1 1 1 ' ' '[ --]'
|
|
|
|
match 1 1 1 1 '$' '[ --]'
|
|
|
|
match 1 1 1 1 '-' '[ --]'
|
|
|
|
match 0 0 0 0 '0' '[ --]'
|
|
|
|
match 1 1 1 1 '-' '[---]'
|
|
|
|
match 1 1 1 1 '-' '[------]'
|
|
|
|
match 0 0 0 0 'j' '[a-e-n]'
|
|
|
|
match 1 1 1 1 '-' '[a-e-n]'
|
|
|
|
match 1 1 1 1 'a' '[!------]'
|
|
|
|
match 0 0 0 0 '[' '[]-a]'
|
|
|
|
match 1 1 1 1 '^' '[]-a]'
|
|
|
|
match 0 0 0 0 '^' '[!]-a]'
|
|
|
|
match 1 1 1 1 '[' '[!]-a]'
|
|
|
|
match 1 1 1 1 '^' '[a^bc]'
|
|
|
|
match 1 1 1 1 '-b]' '[a-]b]'
|
|
|
|
match 0 0 0 0 '\' '[\]'
|
|
|
|
match 1 1 1 1 '\' '[\\]'
|
|
|
|
match 0 0 0 0 '\' '[!\\]'
|
|
|
|
match 1 1 1 1 'G' '[A-\\]'
|
|
|
|
match 0 0 0 0 'aaabbb' 'b*a'
|
|
|
|
match 0 0 0 0 'aabcaa' '*ba*'
|
|
|
|
match 1 1 1 1 ',' '[,]'
|
|
|
|
match 1 1 1 1 ',' '[\\,]'
|
|
|
|
match 1 1 1 1 '\' '[\\,]'
|
|
|
|
match 1 1 1 1 '-' '[,-.]'
|
|
|
|
match 0 0 0 0 '+' '[,-.]'
|
|
|
|
match 0 0 0 0 '-.]' '[,-.]'
|
|
|
|
match 1 1 1 1 '2' '[\1-\3]'
|
|
|
|
match 1 1 1 1 '3' '[\1-\3]'
|
|
|
|
match 0 0 0 0 '4' '[\1-\3]'
|
|
|
|
match 1 1 1 1 '\' '[[-\]]'
|
|
|
|
match 1 1 1 1 '[' '[[-\]]'
|
|
|
|
match 1 1 1 1 ']' '[[-\]]'
|
|
|
|
match 0 0 0 0 '-' '[[-\]]'
|
2012-10-15 08:25:55 +02:00
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
# Test recursion
|
|
|
|
match 1 1 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
|
|
|
|
match 0 0 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
|
|
|
|
match 0 0 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
|
|
|
|
match 1 1 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
|
|
|
|
match 0 0 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
|
|
|
|
match 1 1 1 1 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
|
|
|
|
match 0 0 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
|
|
|
|
match 0 0 0 0 foo '*/*/*'
|
|
|
|
match 0 0 0 0 foo/bar '*/*/*'
|
|
|
|
match 1 1 1 1 foo/bba/arr '*/*/*'
|
|
|
|
match 0 0 1 1 foo/bb/aa/rr '*/*/*'
|
|
|
|
match 1 1 1 1 foo/bb/aa/rr '**/**/**'
|
|
|
|
match 1 1 1 1 abcXdefXghi '*X*i'
|
|
|
|
match 0 0 1 1 ab/cXd/efXg/hi '*X*i'
|
|
|
|
match 1 1 1 1 ab/cXd/efXg/hi '*/*X*/*/*i'
|
|
|
|
match 1 1 1 1 ab/cXd/efXg/hi '**/*X*/**/*i'
|
2013-01-01 03:44:07 +01:00
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
# Extra pathmatch tests
|
|
|
|
match 0 0 0 0 foo fo
|
|
|
|
match 1 1 1 1 foo/bar foo/bar
|
|
|
|
match 1 1 1 1 foo/bar 'foo/*'
|
|
|
|
match 0 0 1 1 foo/bba/arr 'foo/*'
|
|
|
|
match 1 1 1 1 foo/bba/arr 'foo/**'
|
|
|
|
match 0 0 1 1 foo/bba/arr 'foo*'
|
wildmatch test: create & test files on disk in addition to in-memory
There has never been any full roundtrip testing of what git-ls-files
and other commands that use wildmatch() actually do, rather we've been
satisfied with just testing the underlying C function.
Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two. Even when we test for those (as with [1]), there was no one
place where you can review how these two modes differ.
Now there is. We now attempt to create a file called $haystack and
match $needle against it for each pair of $needle and $haystack that
we were passing to test-wildmatch.
If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.
A notable exception to this is Windows, where due to the reasons
explained in [2] the shellscript emulation layer might fake the
creation of a file such as "*", and "test -e" for it will succeed
since it just got created with some character that maps to "*", but
git ls-files won't be fooled by this.
Thus we need to skip creating certain filenames entirely on Windows,
the list here might be overly aggressive. I don't have access to a
Windows system to test this.
As a result of doing these tests we can now see the cases where these
two ways of testing wildmatch differ:
* Creating a file called 'a[]b' and running ls-files 'a[]b' will show
that file, but wildmatch("a[]b", "a[]b") will not match
* wildmatch() won't match a file called \ against \, but ls-files
will.
* `git --glob-pathspecs ls-files 'foo**'` will match a file
'foo/bba/arr', but wildmatch won't, however pathmatch will.
This seems like a bug to me, the two are otherwise equivalent as
these tests show.
This also reveals the case discussed in [1], since 2.16.0 '' is now an
error as far as ls-files is concerned, but wildmatch() itself happily
accepts it.
1. 9e4e8a64c2 ("pathspec: die on empty strings as pathspec",
2017-06-06)
2. nycvar.QRO.7.76.6.1801052133380.1337@wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet
(https://public-inbox.org/git/?q=nycvar.QRO.7.76.6.1801052133380.1337%40wbunaarf-fpuvaqryva.tvgsbejvaqbjf.bet)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30 22:21:22 +01:00
|
|
|
match 0 0 1 1 \
|
|
|
|
1 1 1 1 foo/bba/arr 'foo**'
|
2018-01-30 22:21:21 +01:00
|
|
|
match 0 0 1 1 foo/bba/arr 'foo/*arr'
|
|
|
|
match 0 0 1 1 foo/bba/arr 'foo/**arr'
|
|
|
|
match 0 0 0 0 foo/bba/arr 'foo/*z'
|
|
|
|
match 0 0 0 0 foo/bba/arr 'foo/**z'
|
|
|
|
match 0 0 1 1 foo/bar 'foo?bar'
|
|
|
|
match 0 0 1 1 foo/bar 'foo[/]bar'
|
|
|
|
match 0 0 1 1 foo/bar 'foo[^a-z]bar'
|
|
|
|
match 0 0 1 1 ab/cXd/efXg/hi '*Xg*i'
|
2013-05-30 12:19:10 +02:00
|
|
|
|
2018-01-30 22:21:21 +01:00
|
|
|
# Extra case-sensitivity tests
|
|
|
|
match 0 1 0 1 'a' '[A-Z]'
|
|
|
|
match 1 1 1 1 'A' '[A-Z]'
|
|
|
|
match 0 1 0 1 'A' '[a-z]'
|
|
|
|
match 1 1 1 1 'a' '[a-z]'
|
|
|
|
match 0 1 0 1 'a' '[[:upper:]]'
|
|
|
|
match 1 1 1 1 'A' '[[:upper:]]'
|
|
|
|
match 0 1 0 1 'A' '[[:lower:]]'
|
|
|
|
match 1 1 1 1 'a' '[[:lower:]]'
|
|
|
|
match 0 1 0 1 'A' '[B-Za]'
|
|
|
|
match 1 1 1 1 'a' '[B-Za]'
|
|
|
|
match 0 1 0 1 'A' '[B-a]'
|
|
|
|
match 1 1 1 1 'a' '[B-a]'
|
|
|
|
match 0 1 0 1 'z' '[Z-y]'
|
|
|
|
match 1 1 1 1 'Z' '[Z-y]'
|
2013-05-30 12:19:10 +02:00
|
|
|
|
2012-10-15 08:25:55 +02:00
|
|
|
test_done
|