summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: e2c2407)
raw | patch | inline | side by side (parent: e2c2407)
author | Johannes Sixt <j6t@kdbg.org> | |
Mon, 9 Feb 2009 09:24:51 +0000 (10:24 +0100) | ||
committer | Johannes Sixt <j6t@kdbg.org> | |
Thu, 19 Mar 2009 20:47:14 +0000 (21:47 +0100) |
On Windows, there is an unfortunate interaction between the MSYS bash and
git's command line processing:
- Since Windows's CMD does not do the wildcard expansion, but passes
arguments like path* through to the programs, the programs must do the
expansion themselves. This happens in the startup code before main() is
entered.
- bash, however, passes the argument "path*" to git, assuming that git will
see the unquoted word unchanged as a single argument.
But actually git expands the unquoted word before main() is entered.
In t2200, not all names that the test case is interested in exist as files
at the time when 'git ls-files' is invoked. git expands "path?" to only
the subset of files the exist, and only that subset was listed, so that the
test failed. We now list all interesting paths explicitly.
In t7004, git exanded the pattern "*a*" to "actual" (the file that stdout
was redirected to), which is not what the was tested for. We fix it by
renaming the output file (and removing any existing files matching *a*).
This was originally fixed by Johannes Schindelin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
git's command line processing:
- Since Windows's CMD does not do the wildcard expansion, but passes
arguments like path* through to the programs, the programs must do the
expansion themselves. This happens in the startup code before main() is
entered.
- bash, however, passes the argument "path*" to git, assuming that git will
see the unquoted word unchanged as a single argument.
But actually git expands the unquoted word before main() is entered.
In t2200, not all names that the test case is interested in exist as files
at the time when 'git ls-files' is invoked. git expands "path?" to only
the subset of files the exist, and only that subset was listed, so that the
test failed. We now list all interesting paths explicitly.
In t7004, git exanded the pattern "*a*" to "actual" (the file that stdout
was redirected to), which is not what the was tested for. We fix it by
renaming the output file (and removing any existing files matching *a*).
This was originally fixed by Johannes Schindelin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
t/t2200-add-update.sh | patch | blob | history | |
t/t7004-tag.sh | patch | blob | history |
diff --git a/t/t2200-add-update.sh b/t/t2200-add-update.sh
index b2ddf5ace3581bc2a7056c61b9d43499b2657b65..5a8d52f2ff5ecfea8a1d4f9d39a2ed4a08c822e0 100755 (executable)
--- a/t/t2200-add-update.sh
+++ b/t/t2200-add-update.sh
echo 2 >path3 &&
echo 2 >path5 &&
git add -u &&
- git ls-files -s "path?" >actual &&
+ git ls-files -s path1 path2 path3 path4 path5 path6 >actual &&
{
echo "100644 $three 0 path1"
echo "100644 $one 1 path3"
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 06e6e179f3fc15698d9dbcecd207fa13a9c2b770..1c27ffb45effdafaace54a29c3ce63f07d6899e6 100755 (executable)
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
EOF
test_expect_success \
'listing tags with substring as pattern must print those matching' '
- git tag -l "*a*" > actual &&
- test_cmp expect actual
+ rm *a* &&
+ git tag -l "*a*" > current &&
+ test_cmp expect current
'
cat >expect <<EOF