git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
POPatrick Ohly <patrick.ohly@intel.com>
Date
Nov 3, 2026, 13:24 UTC
Message-ID
<yrjh1p92qc7w.fsf@pohly-mobl1.fritz.box>
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

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.
Versions tested

┌───────────────────────────────────────────────────────┬────────┐ │ Version │ Result │ ├───────────────────────────────────────────────────────┼────────┤ │ 2.39.5, 2.43.4, 2.45.2, 2.47.2, 2.49.1, 2.52.0 │ OK │ ├───────────────────────────────────────────────────────┼────────┤ │ 2.54.0, 2.56.0 │ fail │ ├───────────────────────────────────────────────────────┼────────┤ │ master (v2.56.0-341-gebdc087dc, built with NO_RUST=1) │ fail │ └───────────────────────────────────────────────────────┴────────┘

Notes

• The remote is github.com over HTTPS. I haven't tried other hosts. • I haven't analysed the cause. My guess is that the new  OBJECT_INFO_SECOND_READ  and reprepare path changes how the promisor lazy fetch is triggered. The client then requests an object by OID that the server refuses with "not our ref". • The failure is deterministic. The first PR head merges fine on 2.52.0 and older.

[System Info]
git version 2.56.GIT (also 2.54.0 and 2.56.0), Linux x86_64 (Debian stable container)
-- 
Best Regards

Patrick Ohly
Cloud Software Architect
Next: Kristofer Karlsson
Message 1 of 5 in “[BUG] Lazy fetch in partial clone fails with "not our ref" since 5946a564 (odb/source: make read_object_info() pluggable)”
  1. Patrick OhlyNov 3, 2026
  2. Kristofer KarlssonNov 4, 2026
  3. Patrick OhlyNov 4, 2026
  4. Patrick SteinhardtNov 4, 2026
  5. Patrick SteinhardtNov 4, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.