Skip to content

Commit 1166419

Browse files
jrngitster
authored andcommitted
Revert "check_repository_format_gently(): refuse extensions for old repositories"
This reverts commit 14c7fa2. The core.repositoryFormatVersion field was introduced in ab9cb76 (Repository format version check., 2005-11-25), providing a welcome bit of forward compatibility, thanks to some welcome analysis by Martin Atukunda. The semantics are simple: a repository with core.repositoryFormatVersion set to 0 should be comprehensible by all Git implementations in active use; and Git implementations should error out early instead of trying to act on Git repositories with higher core.repositoryFormatVersion values representing new formats that they do not understand. A new repository format did not need to be defined until 00a09d5 (introduce "extensions" form of core.repositoryformatversion, 2015-06-23). This provided a finer-grained extension mechanism for Git repositories. In a repository with core.repositoryFormatVersion set to 1, Git implementations can act on "extensions.*" settings that modify how a repository is interpreted. In repository format version 1, unrecognized extensions settings cause Git to error out. What happens if a user sets an extension setting but forgets to increase the repository format version to 1? The extension settings were still recognized in that case; worse, unrecognized extensions settings do *not* cause Git to error out. So combining repository format version 0 with extensions settings produces in some sense the worst of both worlds. To improve that situation, since 14c7fa2 (check_repository_format_gently(): refuse extensions for old repositories, 2020-06-05) Git instead ignores extensions in v0 mode. This way, v0 repositories get the historical (pre-2015) behavior and maintain compatibility with Git implementations that do not know about the v1 format. Unfortunately, users had been using this sort of configuration and this behavior change came to many as a surprise: - users of "git config --worktree" that had followed its advice to enable extensions.worktreeConfig (without also increasing the repository format version) would find their worktree configuration no longer taking effect - tools such as copybara[*] that had set extensions.partialClone in existing repositories (without also increasing the repository format version) would find that setting no longer taking effect The behavior introduced in 14c7fa2 might be a good behavior if we were traveling back in time to 2015, but we're far too late. For some reason I thought that it was what had been originally implemented and that it had regressed. Apologies for not doing my research when 14c7fa2 was under development. Let's return to the behavior we've had since 2015: always act on extensions.* settings, regardless of repository format version. While we're here, include some tests to describe the effect on the "upgrade repository version" code path. [*] google/copybara@ca76c0b Reported-by: Johannes Schindelin <[email protected]> Signed-off-by: Jonathan Nieder <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 14c7fa2 commit 1166419

File tree

2 files changed

+16
-11
lines changed

2 files changed

+16
-11
lines changed

setup.c

Lines changed: 3 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -507,15 +507,9 @@ static int check_repository_format_gently(const char *gitdir, struct repository_
507507
die("%s", err.buf);
508508
}
509509

510-
if (candidate->version >= 1) {
511-
repository_format_precious_objects = candidate->precious_objects;
512-
set_repository_format_partial_clone(candidate->partial_clone);
513-
repository_format_worktree_config = candidate->worktree_config;
514-
} else {
515-
repository_format_precious_objects = 0;
516-
set_repository_format_partial_clone(NULL);
517-
repository_format_worktree_config = 0;
518-
}
510+
repository_format_precious_objects = candidate->precious_objects;
511+
set_repository_format_partial_clone(candidate->partial_clone);
512+
repository_format_worktree_config = candidate->worktree_config;
519513
string_list_clear(&candidate->unknown_extensions, 0);
520514

521515
if (repository_format_worktree_config) {

t/t0410-partial-clone.sh

Lines changed: 13 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -42,14 +42,25 @@ test_expect_success 'convert shallow clone to partial clone' '
4242
test_cmp_config -C client 1 core.repositoryformatversion
4343
'
4444

45-
test_expect_success 'convert shallow clone to partial clone must fail with any extension' '
45+
test_expect_success 'converting to partial clone fails with noop extension' '
4646
rm -fr server client &&
4747
test_create_repo server &&
4848
test_commit -C server my_commit 1 &&
4949
test_commit -C server my_commit2 1 &&
5050
git clone --depth=1 "file://$(pwd)/server" client &&
5151
test_cmp_config -C client 0 core.repositoryformatversion &&
52-
git -C client config extensions.partialclone origin &&
52+
git -C client config extensions.noop true &&
53+
test_must_fail git -C client fetch --unshallow --filter="blob:none"
54+
'
55+
56+
test_expect_success 'converting to partial clone fails with unrecognized extension' '
57+
rm -fr server client &&
58+
test_create_repo server &&
59+
test_commit -C server my_commit 1 &&
60+
test_commit -C server my_commit2 1 &&
61+
git clone --depth=1 "file://$(pwd)/server" client &&
62+
test_cmp_config -C client 0 core.repositoryformatversion &&
63+
git -C client config extensions.nonsense true &&
5364
test_must_fail git -C client fetch --unshallow --filter="blob:none"
5465
'
5566

0 commit comments

Comments
 (0)