git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git clone with --dissociate sometimes fails to check out target commit

From
RVRasmus Villemoes <ravi@prevas.dk>
Date
May 4, 2026, 08:20 UTC
Message-ID
<87h5onsi0f.fsf@prevas.dk>
Hi

We have now seen this error a couple of times in our CI, and this time I managed to grab a snapshot of the local mirror for which it fails. The failing command is

  git clone --verbose --depth=20 --branch=whinlatter --reference-if-able=/yocto/meta-mirrors/core --dissociate https://git.openembedded.org/openembedded-core core
  Cloning into 'core'...
  POST git-upload-pack (388 bytes)
  POST git-upload-pack (986 bytes)
  POST git-upload-pack (gzip 1836 to 958 bytes)
  fatal: unable to parse commit 8751ec83421192fc0f8495fb95798f9eb7be77a0
  warning: Clone succeeded, but checkout failed.
  You can inspect what was checked out with 'git status'
  and retry with 'git restore --source=HEAD :/'

I wrapped up that local copy /yocto/meta-mirrors/core in a tarball, but it's ~200M, and I don't know another way of reproducing. I also don't have a better way of sharing such a file than [1], apologies.

Using that repository as both the remote url to clone and the local reference, I can consistently reproduce the problem. That is:

  cd /tmp
  # fetch that core.tar.gz
  mkdir upstream-core local-core
  tar -xf core.tar.gz -C upstream-core/
  tar -xf core.tar.gz -C local-core/
  git clone --verbose --branch=whinlatter --reference-if-able=/tmp/local-core --dissociate --depth=20 file:///tmp/upstream-core core

fails in the same way, with both git 2.47.3 (Debian trixie) and 2.53.0 (Arch). Removing --depth=20 doesn't change anything, neither does removing --branch=whinlatter (except of course for the commit it tries to check out). But dropping --dissociate, the clone works as expected.

It doesn't happen very often, the last time was around January 30, where it was for another repository (https://github.com/openembedded/meta-openembedded.git), but exactly the same symptoms, so about 100 nightly pipelines ago.

Are we using --dissociate wrongly, or are we perhaps not maintaining those local mirror repos properly? They are essentially just created with 'git clone --mirror', with 'git remote update' run periodically.

Naively, I'd expect the effects of --dissociate to only happen after everything else the clone command does has been done, but it seems that the ties to the reference repo are cut too soon.

Rasmus
[1] https://prevasonline-my.sharepoint.com/:u:/g/personal/rasmus_villemoes_prevas_dk/IQCRaxpwj5NfQYZNQJWc9PJTAY0C33XvXn8CnqPEdPAbpDA?e=zQAfg7
Next: Jeff King
Message 1 of 4 in “git clone with --dissociate sometimes fails to check out target commit”
  1. Rasmus VillemoesMay 4, 2026
  2. Jeff KingMay 4, 2026
  3. Jeff KingMay 4, 2026
  4. Rasmus VillemoesMay 4, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.