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

From
Patrick Steinhardt <hidden>
Date
2026-11-04 12:22:24
Reply to
Patrick Ohly, 2026-11-04
On Wed, Nov 04, 2026 at 12:56:53PM +0100, Patrick Ohly wrote:
Kristofer Karlsson [off-list ref] writes:
quoted
On Tue, 3 Nov 2026 at 14:31, Patrick Ohly [off-list ref] wrote:
quoted
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]: [ref]
Thread (5 messages) 5 messages, 3 authors, last reply 4d ago
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help