Re: git clone of empty repositories doesn't preserve hash
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 5, 2023, 21:15 UTC
- Message-ID
- <xmqq355euj2i.fsf@gitster.g>
- In-Reply-To
- <xmqqa5zmukp5.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> I guess we only need to touch "git clone" then. Without being > asked, it advertsizes object-format=sha256 already, and when the > maestro repository is prepared without --object-format=sha256, > upload-pack advertises object-format=sha1 instead. So it probably > is just the matter of capturing it and using it to populate the > extensions.objectformat with an appropriate value.
It turns out that there was a readily mimickable example in 3d8314f8 (clone: propagate empty remote HEAD even with other branches, 2022-07-07). The commit lifted code out of a block, in which we know we are copying from a non-empty repository, to execute also when talking with an empty repository. The recording of the hash-algorithm in the extensions section is done in the same way, so we can do the same "fix".
----- >8 ----- Subject: [PATCH] clone: propagate object-format when cloning from void
A user could prepare an empty repository and set it to use SHA256 as the object format. The new repository created by "git clone" from such a repository however would not record that it is expecting objects in the same SHA256 format. This works as expected if the source repository is not empty.
Just like we started copying the name of the primary branch from the remote repository even if it is unborn in 3d8314f8 (clone: propagate empty remote HEAD even with other branches, 2022-07-07), lift the code that records the object format out of the block executed only when cloning from an instantiated repository, so that it works also when cloning from an empty repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin/clone.c | 11 ++++++----- t/t5702-protocol-v2.sh | 11 +++++++++++ 2 files changed, 17 insertions(+), 5 deletions(-)
diff --git c/builtin/clone.c w/builtin/clone.c index 462c286274..8f16d18a43 100644 --- c/builtin/clone.c +++ w/builtin/clone.c @@ -910,6 +910,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) int err = 0, complete_refs_before_fetch = 1; int submodule_progress; int filter_submodules = 0; + int hash_algo; struct transport_ls_refs_options transport_ls_refs_options = TRANSPORT_LS_REFS_OPTIONS_INIT; @@ -1298,15 +1299,15 @@ int cmd_clone(int argc, const char **argv, const char *prefix) } } - if (mapped_refs) { - int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport)); - /* * Now that we know what algorithm the remote side is using, * let's set ours to the same thing. */ - initialize_repository_version(hash_algo, 1); - repo_set_hash_algo(the_repository, hash_algo); + hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport)); + initialize_repository_version(hash_algo, 1); + repo_set_hash_algo(the_repository, hash_algo); + + if (mapped_refs) { /* * transport_get_remote_refs() may return refs with null sha-1 * in mapped_refs (see struct transport->get_refs_list diff --git c/t/t5702-protocol-v2.sh w/t/t5702-protocol-v2.sh index 71aabe30b7..6af5c2062f 100755 --- c/t/t5702-protocol-v2.sh +++ w/t/t5702-protocol-v2.sh @@ -269,6 +269,17 @@ test_expect_success 'clone propagates unborn HEAD from non-empty repo' ' grep "warning: remote HEAD refers to nonexistent ref" stderr ' +test_expect_success 'clone propagates object-format from empty repo' ' + test_when_finished "rm -fr src256 dst256" && + + echo sha256 >expect && + git init --object-format=sha256 src256 && + git clone src256 dst256 && + git -C dst256 rev-parse --show-object-format >actual && + + test_cmp expect actual +' + test_expect_success 'bare clone propagates unborn HEAD from non-empty repo' ' test_when_finished "rm -rf file_unborn_parent file_unborn_child.git" &&