From: Patrick Steinhardt Date: Wed, 04 Nov 2026 12:22:18 GMT Subject: Re: [BUG] Lazy fetch in partial clone fails with "not our ref" since 5946a564 (odb/source: make read_object_info() pluggable) Message-ID: In-Reply-To: On Wed, Nov 04, 2026 at 12:56:53PM +0100, Patrick Ohly wrote: > Kristofer Karlsson writes: > > > On Tue, 3 Nov 2026 at 14:31, Patrick Ohly wrote: > >> > >> Hello, > >> > >> "git merge" in a blobless partial clone fails with "not our ref" while > >> lazily fetching a missing object. This started to occur today in the > >> Kubernetes CI, completely breaking the merging of PRs. We should have > >> been using git 2.54.0, the affected version, for a few days at least > >> without issues, so it can't be ruled out that this is at least partly > >> caused by a change on the GitHub side. We are about to revert to git > >> 2.52.0 to unblock the Kubernetes project. > >> > >> [...] > >> > >> I bisected v2.52.0 (good) to v2.54.0 (bad). The first bad commit is: > >> > >> 5946a564cddc0bf471f27ae4c3fe205441e3ef65 > >> odb/source: make `read_object_info()` function pluggable > >> > >> The parent, 3bc3177ad7 ( 2.53.0.185.g3bc3177ad7 ), is good. > > > > Thanks for the detailed report. I think I have found the cause: I > > can reproduce the failure with your steps and make it go away with a > > small change to the loose object cache. > > Any idea why this suddenly started to occur? > > We were using 2.54.0 for several days without issues prior to the > failure. For example, > https://storage.googleapis.com/kubernetes-ci-logs/pr-logs/pull/batch/pull-kubernetes-cmd/2117551425255903232/clone-log.txt > merged several different PRs for > https://prow.k8s.io/view/gs/kubernetes-ci-logs/pr-logs/pull/batch/pull-kubernetes-cmd/2117551425255903232 > using > us-docker.pkg.dev/k8s-infra-prow/images/clonerefs:v20261028-c06373a3e > as environment. It contains 2.54.0. The issue here depends on the actual objects IDs that you're merging. You need to merge at least one object with the same first two hex characters into a newly written object that same first two characters. If so, you can trigger a stale loose object cache that makes Git think that the object does not exist locally, and it then tries to fetch it from the promisor remote. I've sent a fix for this bug via [1]. Thanks! Patrick [1]: <20261104-pks-odb-loose-stale-cache-v1-0-a00d5cdb5e7d@pks.im>