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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.