1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 13:57:54 +01:00
git/t/t1302-repo-version.sh

48 lines
1.2 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Nguyễn Thái Ngọc Duy
#
test_description='Test repository version check'
. ./test-lib.sh
cat >test.patch <<EOF
diff --git a/test.txt b/test.txt
new file mode 100644
--- /dev/null
+++ b/test.txt
@@ -0,0 +1 @@
+123
EOF
test_create_repo "test"
test_create_repo "test2"
GIT_CONFIG=test2/.git/config git config core.repositoryformatversion 99 || exit 1
test_expect_success 'gitdir selection on normal repos' '
(test "$(git config core.repositoryformatversion)" = 0 &&
cd test &&
test "$(git config core.repositoryformatversion)" = 0)'
# Make sure it would stop at test2, not trash
test_expect_success 'gitdir selection on unsupported repo' '
(cd test2 &&
test "$(git config core.repositoryformatversion)" = 99)'
test_expect_success 'gitdir not required mode' '
(git apply --stat test.patch &&
cd test && git apply --stat ../test.patch &&
cd ../test2 && git apply --stat ../test.patch)'
test_expect_success 'gitdir required mode on normal repos' '
(git apply --check --index test.patch &&
cd test && git apply --check --index ../test.patch)'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'gitdir required mode on unsupported repo' '
(cd test2 && test_must_fail git apply --check --index ../test.patch)
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
'
test_done