Re: git clone with --dissociate sometimes fails to check out target commit
On Mon, May 04, 2026 at 05:51:10AM -0400, Jeff King wrote:
Show 6 quoted lines
> 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
Jeff King <peff@peff.net>