Git development
 help / color / mirror / Atom feed
From: Rasmus Villemoes <ravi@prevas.dk>
To: git@vger.kernel.org
Cc: emkan@prevas.dk
Subject: git clone with --dissociate sometimes fails to check out target commit
Date: Mon, 04 May 2026 10:20:32 +0200	[thread overview]
Message-ID: <87h5onsi0f.fsf@prevas.dk> (raw)

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

             reply	other threads:[~2026-05-04  8:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04  8:20 Rasmus Villemoes [this message]
2026-05-04  9:51 ` git clone with --dissociate sometimes fails to check out target commit Jeff King
2026-05-04  9:54   ` Jeff King
2026-05-04 11:36   ` Rasmus Villemoes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h5onsi0f.fsf@prevas.dk \
    --to=ravi@prevas.dk \
    --cc=emkan@prevas.dk \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox