On Wed, Apr 05, 2023 at 02:15:33PM -0700, Junio C Hamano wrote: > ----- >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. Heh, our mails just crossed, but I stumbled upon the same patch. So yes, this looks good to me. I suspect that setting the flag in the_repository might not matter, since we do not have any refs or objects to manipulate, and what we care about here is that initialize_repository_version() is run. But I agree that the two conceptually belong together, and hoisting both out of the block is the right thing to do. > 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 > +' And this test looks straightforward. Very nice. -Peff
