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
next 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