From: Jeff King <peff@peff.net>
Date: Mon, 04 May 2026 09:54:42 GMT
Subject: Re: git clone with --dissociate sometimes fails to check out target commit
Message-ID: <20260504095442.GA603346@coredump.intra.peff.net>
In-Reply-To: <20260504095110.GA599780@coredump.intra.peff.net>

On Mon, May 04, 2026 at 05:51:10AM -0400, Jeff King wrote:

> No, you're using it correctly. The dissociate step should copy all of
> the shared objects into the new repo, so it shouldn't matter whether we
> do it before or after checkout. The objects are there either way.
> 
> But there's an interesting bug here with commit graphs. What happens is
> this:

Oh, and ironically dissociating later _would_ fix this bug, like so:

diff --git a/builtin/clone.c b/builtin/clone.c
index fba3c9c508..7b7c83c717 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1616,11 +1616,6 @@ int cmd_clone(int argc,
 	transport_unlock_pack(transport, 0);
 	transport_disconnect(transport);
 
-	if (option_dissociate) {
-		odb_close(the_repository->objects);
-		dissociate_from_references();
-	}
-
 	if (option_sparse_checkout && git_sparse_checkout_init(dir))
 		return 1;
 
@@ -1630,6 +1625,11 @@ int cmd_clone(int argc,
 		       filter_submodules,
 		       ref_storage_format);
 
+	if (option_dissociate) {
+		odb_close(the_repository->objects);
+		dissociate_from_references();
+	}
+
 	list_objects_filter_release(&filter_options);
 
 	string_list_clear(&option_not, 0);


But only because we are working around it: if we dissociate at the very
end, then there is no in-process code that will look at the objects
after that odb_close() call, and thus the bug cannot be triggered. It
would still potentially be lurking for other odb_close() callers,
though.

-Peff