All of lore.kernel.org
 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 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.