git/t/t1302-repo-version.sh

131 строка
2.4 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
#
# Copyright (c) 2007 Nguyễn Thái Ngọc Duy
#
test_description='Test repository version check'
. ./test-lib.sh
test_expect_success 'setup' '
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 --file=test2/.git/config core.repositoryformatversion 99
'
test_expect_success 'gitdir selection on normal repos' '
echo 0 >expect &&
git config core.repositoryformatversion >actual &&
(
cd test &&
git config core.repositoryformatversion >../actual2
) &&
test_cmp expect actual &&
test_cmp expect actual2
'
test_expect_success 'gitdir selection on unsupported repo' '
# Make sure it would stop at test2, not trash
echo 99 >expect &&
(
cd test2 &&
git config core.repositoryformatversion >../actual
) &&
test_cmp expect actual
'
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' '
git apply --check --index test.patch &&
(
cd test &&
git apply --check --index ../test.patch
) &&
(
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 12:50:53 +03:00
'
introduce "extensions" form of core.repositoryformatversion Normally we try to avoid bumps of the whole-repository core.repositoryformatversion field. However, it is unavoidable if we want to safely change certain aspects of git in a backwards-incompatible way (e.g., modifying the set of ref tips that we must traverse to generate a list of unreachable, safe-to-prune objects). If we were to bump the repository version for every such change, then any implementation understanding version `X` would also have to understand `X-1`, `X-2`, and so forth, even though the incompatibilities may be in orthogonal parts of the system, and there is otherwise no reason we cannot implement one without the other (or more importantly, that the user cannot choose to use one feature without the other, weighing the tradeoff in compatibility only for that particular feature). This patch documents the existing repositoryformatversion strategy and introduces a new format, "1", which lets a repository specify that it must run with an arbitrary set of extensions. This can be used, for example: - to inform git that the objects should not be pruned based only on the reachability of the ref tips (e.g, because it has "clone --shared" children) - that the refs are stored in a format besides the usual "refs" and "packed-refs" directories Because we bump to format "1", and because format "1" requires that a running git knows about any extensions mentioned, we know that older versions of the code will not do something dangerous when confronted with these new formats. For example, if the user chooses to use database storage for refs, they may set the "extensions.refbackend" config to "db". Older versions of git will not understand format "1" and bail. Versions of git which understand "1" but do not know about "refbackend", or which know about "refbackend" but not about the "db" backend, will refuse to run. This is annoying, of course, but much better than the alternative of claiming that there are no refs in the repository, or writing to a location that other implementations will not read. Note that we are only defining the rules for format 1 here. We do not ever write format 1 ourselves; it is a tool that is meant to be used by users and future extensions to provide safety with older implementations. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-23 13:53:58 +03:00
check_allow () {
git rev-parse --git-dir >actual &&
echo .git >expect &&
test_cmp expect actual
}
check_abort () {
test_must_fail git rev-parse --git-dir
}
# avoid git-config, since it cannot be trusted to run
# in a repository with a broken version
mkconfig () {
echo '[core]' &&
echo "repositoryformatversion = $1" &&
shift &&
if test $# -gt 0; then
echo '[extensions]' &&
for i in "$@"; do
echo "$i"
done
fi
}
while read outcome version extensions; do
test_expect_success "$outcome version=$version $extensions" "
mkconfig $version $extensions >.git/config &&
check_${outcome}
"
done <<\EOF
allow 0
allow 1
allow 1 noop
abort 1 no-such-extension
allow 0 no-such-extension
EOF
test_expect_success 'precious-objects allowed' '
mkconfig 1 preciousObjects >.git/config &&
check_allow
'
test_expect_success 'precious-objects blocks destructive repack' '
test_must_fail git repack -ad
'
test_expect_success 'other repacks are OK' '
test_commit foo &&
git repack
'
test_expect_success 'precious-objects blocks prune' '
test_must_fail git prune
'
test_expect_success 'gc runs without complaint' '
git gc
'
test_done