Re: [BUG] Lazy fetch in partial clone fails with "not our ref" since 5946a564 (odb/source: make read_object_info() pluggable)

From: Patrick Steinhardt <ps@pks.im>
Date: Nov 4, 2026, 12:19 UTC
Message-ID: <ausi3vZtRdB_40Bc@pks.im>
In-Reply-To: <yrjh1p92qc7w.fsf@pohly-mobl1.fritz.box>

Hi,

On Tue, Nov 03, 2026 at 02:24:51PM +0100, Patrick Ohly wrote:

Show 30 quoted lines

> 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.
> 
> What follows is an agent analysis of the problem. I'm not rewriting it
> because it seems succinct and useful as-is:
> 
> What did you do before the bug happened? (Steps to reproduce)
> 
> git init k && cd k
> R=https://github.com/kubernetes/kubernetes.git
> git fetch --filter=blob:none $R 6575724b63e50cd5dd454e774bc293c6de1e4e12
> git checkout 6575724b63e50cd5dd454e774bc293c6de1e4e12
> git fetch --filter=blob:none $R 787dd27af44c14c22d3bae46bf62b4a0271efc06
> git -c user.name=a -c user.email=a@b merge --no-ff 787dd27af44c14c22d3bae46bf62b4a0271efc06
> 
> What did you expect to happen?
> 
> The merge succeeds, with missing blobs fetched lazily from the promisor remote.
> 
> What happened instead?
> 
> fatal: remote error: upload-pack: not our ref 27b64cc863187e62d8b47196a78c045412d32ac9
> fatal: could not fetch 3c804b88bcf177a1435ba770fa9054c25e1315c3 from promisor remote

thanks for this well-written report, I can reproduce the bug.

Show 8 quoted lines

> Bisect result
> 
> 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.

The root cause of this is actually older than the commit you have bisected to: we never update the loose object cache when writing objects, so in case we have already populated the specific sharding directory that the newly written object belongs to the cache will be stale. And as object existence checks are answered via the cache, we will now pretend as if the object didn't exist at all.

The commit changes logic to not flush the loose object cache anymore in case we cannot find an object. But the fact that flushing the loose object cache fixes the bug was pure coincidence, as it required us to do interleaving objects reads and object existence checks.

I've sent fixes via [1]. Thanks!

Patrick

[1]: <20261104-pks-odb-loose-stale-cache-v1-0-a00d5cdb5e7d@pks.im>