{"thread":{"id":"65620","subject":"git clone fails when using --dissociate together with a reference repository that contains a commit-graph","startedAt":"2026-05-12T07:35:52Z","lastAt":"2026-05-12T18:38:36Z","messageCount":2,"participants":["Daniel Mach","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"543151","messageId":"6ae85515-9373-4c9e-90d2-5e4176590c5b@suse.com","threadId":"65620","inReplyTo":null,"subject":"git clone fails when using --dissociate together with a reference repository that contains a commit-graph","fromName":"Daniel Mach","fromEmail":"daniel.mach@suse.com","sentAt":"2026-05-12T07:35:49Z","receivedAt":"2026-05-12T07:35:52Z","isPatch":false,"body":"Hi,\n\nI've stumbled upon a bug that the following command failed:\n\n$ git clone --reference --dissociate\nfatal: unable to parse commit \nwarning: Clone succeeded, but checkout failed.\nYou can inspect what was checked out with 'git status'\nand retry with 'git restore --source=HEAD :/'\n\nOmitting --dissociate fixed the error, but it wasn't clear to me what \nmight be the root cause.\n\n$ git --version\ngit version 2.54.0\n\nWith the help of AI I was able to create a reproducer (see the attached \nscript).\nI have verified that the reproducer works and also simplified it.\n\nAI generated report (take it with a grain of salt):\n* The Bug: During dissociation, Git correctly repacks objects and \nremoves the objects/info/alternates file. However, the git clone process \nhas already initialized its object store including the alternate's \ncommit-graph.\n   After dissociation, it fails to \"forget\" or reload the object store, \nleading to a crash when it tries to use the commit-graph (which refers \nto the now-unlinked alternate) to perform the initial checkout.\n* Proof of state: As shown in the script output, a manual git checkout \nimmediately after the failure succeeds, proving the repository is \nstructurally sound but the clone process itself was in an inconsistent \nstate.\n* Workaround: Passing -c core.commitGraph=false to the clone command \nprevents the crash.\n\nregards,\nDaniel\n\n"},{"id":"543210","messageId":"20260512183835.GB70851@coredump.intra.peff.net","threadId":"65620","inReplyTo":"6ae85515-9373-4c9e-90d2-5e4176590c5b@suse.com","subject":"Re: git clone fails when using --dissociate together with a reference repository that contains a commit-graph","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-05-12T18:38:35Z","receivedAt":"2026-05-12T18:38:36Z","isPatch":false,"body":"On Tue, May 12, 2026 at 09:35:49AM +0200, Daniel Mach wrote:\n\n> I've stumbled upon a bug that the following command failed:\n> \n> $ git clone --reference --dissociate\n> fatal: unable to parse commit \n> warning: Clone succeeded, but checkout failed.\n> You can inspect what was checked out with 'git status'\n> and retry with 'git restore --source=HEAD :/'\n> \n> Omitting --dissociate fixed the error, but it wasn't clear to me what might\n> be the root cause.\n\nI think this is the same bug discussed here:\n\n https://lore.kernel.org/git/20260504095110.GA599780@coredump.intra.peff.net/\n\nI haven't worked up a more polished patch yet because I was trying to\ndecide between the approach given there (to lazily fall back to manual\nparsing) versus filling in all of the dependent tree fields when closing\nthe commit-graph. Which one is cheaper depends on the access patterns\n(how many commits will actually be looked at post-close, versus how many\nwere ever loaded).\n\n-Peff\n"}]}