2012-10-15 08:25:55 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='wildmatch tests'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
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
|