summaryrefslogtreecommitdiff
path: root/t/t1302-repo-version.sh
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2020-07-16 12:25:13 (GMT)
committerJunio C Hamano <gitster@pobox.com>2020-07-16 17:39:45 (GMT)
commitec91ffca0455e1a8a0525fb2a10814447d80c456 (patch)
treec3c5b7f3a29ee9c1c30c347e7a0be4c55eb928cd /t/t1302-repo-version.sh
parent62f2eca6065d0c27b0ea3b7806a590466ea04960 (diff)
downloadgit-ec91ffca0455e1a8a0525fb2a10814447d80c456.zip
git-ec91ffca0455e1a8a0525fb2a10814447d80c456.tar.gz
git-ec91ffca0455e1a8a0525fb2a10814447d80c456.tar.bz2
verify_repository_format(): complain about new extensions in v0 repo
We made the mistake in the past of respecting extensions.* even when the repository format version was set to 0. This is bad because forgetting to bump the repository version means that older versions of Git (which do not know about our extensions) won't complain. I.e., it's not a problem in itself, but it means your repository is in a state which does not give you the protection you think you're getting from older versions. For compatibility reasons, we are stuck with that decision for existing extensions. However, we'd prefer not to extend the damage further. We can do that by catching any newly-added extensions and complaining about the repository format. Note that this is a pretty heavy hammer: we'll refuse to work with the repository at all. A lesser option would be to ignore (possibly with a warning) any new extensions. But because of the way the extensions are handled, that puts the burden on each new extension that is added to remember to "undo" itself (because they are handled before we know for sure whether we are in a v1 repo or not, since we don't insist on a particular ordering of config entries). So one option would be to rewrite that handling to record any new extensions (and their values) during the config parse, and then only after proceed to handle new ones only if we're in a v1 repository. But I'm not sure if it's worth the trouble: - ignoring extensions is likely to end up with broken results anyway (e.g., ignoring a proposed objectformat extension means parsing any object data is likely to encounter errors) - this is a sign that whatever tool wrote the extension field is broken. We may be better off notifying immediately and forcefully so that such tools don't even appear to work accidentally. The only downside is that fixing the situation is a little tricky, because programs like "git config" won't want to work with the repository. But: git config --file=.git/config core.repositoryformatversion 1 should still suffice. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t1302-repo-version.sh')
-rwxr-xr-xt/t1302-repo-version.sh3
1 files changed, 3 insertions, 0 deletions
diff --git a/t/t1302-repo-version.sh b/t/t1302-repo-version.sh
index ce4cff1..248d7a4 100755
--- a/t/t1302-repo-version.sh
+++ b/t/t1302-repo-version.sh
@@ -83,6 +83,9 @@ allow 1
allow 1 noop
abort 1 no-such-extension
allow 0 no-such-extension
+allow 0 noop
+abort 0 noop-v1
+allow 1 noop-v1
EOF
test_expect_success 'precious-objects allowed' '