2007-12-05 14:33:32 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2007 Nguyễn Thái Ngọc Duy
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
test_description='Test repository version check'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
2010-09-07 03:52:27 +02:00
|
|
|
test_expect_success 'setup' '
|
2020-05-25 21:59:13 +02:00
|
|
|
test_oid_cache <<-\EOF &&
|
|
|
|
|
version sha1:0
|
|
|
|
|
version sha256:1
|
|
|
|
|
EOF
|
2010-09-07 03:52:27 +02:00
|
|
|
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
|
2007-12-05 14:33:32 +01:00
|
|
|
|
2010-09-07 03:52:27 +02:00
|
|
|
test_create_repo "test" &&
|
|
|
|
|
test_create_repo "test2" &&
|
2014-03-21 00:17:01 +01:00
|
|
|
git config --file=test2/.git/config core.repositoryformatversion 99
|
2010-09-07 03:52:27 +02:00
|
|
|
'
|
2007-12-05 14:33:32 +01:00
|
|
|
|
|
|
|
|
test_expect_success 'gitdir selection on normal repos' '
|
2020-05-25 21:59:13 +02:00
|
|
|
echo $(test_oid version) >expect &&
|
2010-09-07 03:52:27 +02:00
|
|
|
git config core.repositoryformatversion >actual &&
|
2016-09-13 05:24:00 +02:00
|
|
|
git -C test config core.repositoryformatversion >actual2 &&
|
2010-09-07 03:52:27 +02:00
|
|
|
test_cmp expect actual &&
|
|
|
|
|
test_cmp expect actual2
|
|
|
|
|
'
|
2007-12-05 14:33:32 +01:00
|
|
|
|
|
|
|
|
test_expect_success 'gitdir selection on unsupported repo' '
|
2010-09-07 03:52:27 +02:00
|
|
|
# Make sure it would stop at test2, not trash
|
config: only read .git/config from configured repos
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config". This
seems like it would be helpful (presumably we haven't set up
the repository yet, so it tries to find it), but it turns
out to be a bad idea for a few reasons:
- it's not sufficient, and therefore hides bugs in a
confusing way. Config will be respected if commands are
run from the top-level of the working tree, but not from
a subdirectory.
- it's not always true that we haven't set up the
repository _yet_; we may not want to do it at all. For
instance, if you run "git init /some/path" from inside
another repository, it should not load config from the
existing repository.
- there might be a path ".git/config", but it is not the
actual repository we would find via setup_git_directory().
This may happen, e.g., if you are storing a git
repository inside another git repository, but have
munged one of the files in such a way that the
inner repository is not valid (e.g., by removing HEAD).
We have at least two bugs of the second type in git-init,
introduced by ae5f677 (lazily load core.sharedrepository,
2016-03-11). It causes init to use git_configset(), which
loads all of the config, including values from the current
repo (if any). This shows up in two ways:
1. If we happen to be in an existing repository directory,
we'll read and respect core.sharedrepository from it,
even though it should have no bearing on the new
repository. A new test in t1301 covers this.
2. Similarly, if we're in an existing repo that sets
core.logallrefupdates, that will cause init to fail to
set it in a newly created repository (because it thinks
that the user's templates already did so). A new test
in t0001 covers this.
We also need to adjust an existing test in t1302, which
gives another example of why this patch is an improvement.
That test creates an embedded repository with a bogus
core.repositoryformatversion of "99". It wants to make sure
that we actually stop at the bogus repo rather than
continuing upward to find the outer repo. So it checks that
"git config core.repositoryformatversion" returns 99. But
that only works because we blindly read ".git/config", even
though we _know_ we're in a repository whose vintage we do
not understand.
After this patch, we avoid reading config from the unknown
vintage repository at all, which is a safer choice. But we
need to tweak the test, since core.repositoryformatversion
will not return 99; it will claim that it could not find the
variable at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 05:24:15 +02:00
|
|
|
test_expect_code 1 git -C test2 config core.repositoryformatversion >actual
|
2010-09-07 03:52:27 +02:00
|
|
|
'
|
2007-12-05 14:33:32 +01:00
|
|
|
|
|
|
|
|
test_expect_success 'gitdir not required mode' '
|
2010-09-06 20:39:54 +02:00
|
|
|
git apply --stat test.patch &&
|
2016-09-13 05:24:00 +02:00
|
|
|
git -C test apply --stat ../test.patch &&
|
|
|
|
|
git -C test2 apply --stat ../test.patch
|
2010-09-07 03:42:54 +02:00
|
|
|
'
|
2007-12-05 14:33:32 +01:00
|
|
|
|
2010-09-07 03:52:27 +02:00
|
|
|
test_expect_success 'gitdir required mode' '
|
|
|
|
|
git apply --check --index test.patch &&
|
2016-09-13 05:24:00 +02:00
|
|
|
git -C test apply --check --index ../test.patch &&
|
|
|
|
|
test_must_fail git -C test2 apply --check --index ../test.patch
|
2008-02-01 10:50:53 +01:00
|
|
|
'
|
2007-12-05 14:33:32 +01: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 12:53:58 +02: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
|
2020-07-16 14:25:13 +02:00
|
|
|
allow 0 noop
|
|
|
|
|
abort 0 noop-v1
|
|
|
|
|
allow 1 noop-v1
|
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 12:53:58 +02:00
|
|
|
EOF
|
|
|
|
|
|
2015-06-23 12:54:11 +02:00
|
|
|
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
|
|
|
|
|
'
|
|
|
|
|
|
2007-12-05 14:33:32 +01:00
|
|
|
test_done
|