Upstream report, FILED: index_thin_pack refuses a base carried later in the same pack
FILED 2026-08-05: https://github.com/GitoxideLabs/gitoxide/issues/2882 (as under the Ignalina account — see .nornir/upstream-gix-base-size.md for the precedent and the account rule).
Found 2026-08-05 by the walk-voucher lane while chasing gunnar.year's week-7 death. gunnar is not blocked on it: the sender was changed instead, in 1cf2dfe, so Selection::client_has now vouches with the exclusion closure alone and never names a base the client cannot already hold.
Why it is filed anyway
The fix on our side cost +0.53% wire bytes and moved thin bases refused from 4 → 74 per corpus run. That is the right trade for us — a refused fetch is a wrong answer and 0.53% is not — but it only works because we own the sender.
A gitoxide-based client fetching from a multi-pack stock-git server meets the same bytes and cannot change the sender. That is the case the issue is for.
What it needs to reproduce
A multi-pack store on the sender. 1d062a8c1d97fd2d04222bb9a0d5c309fde57796 is held twice — whole in the pack whose push introduced its dependant (spliced by --fix-thin), and as a delta in the pack whose push introduced it — so the entry copier cannot re-point the second delta and emits it naming the base by oid.
A single-pack store cannot produce it, which is the fixture trap this tree has now hit twelve times: git clone --bare repacks and writes no .bitmap, so a corpus built that way is single-pack and every pack it produces passes. The reproduction only appeared after rebuilding 19 repositories in the production shape — 12 pushes, 12 packs, no repack.
The measurement
46 real served fetches, judged twice on the same bytes, sha1 and sha256:
| receiver | verdict |
stock git 2.53.0 index-pack --strict --fix-thin + fsck --full --strict |
46 of 46 accept |
gitoxide index_thin_pack |
13 of 46 refuse |
The 13 span 11 of the 19 repositories.
What we could not determine
Whether gitoxide's behaviour is a defect or the intended stricter reading. The issue says so rather than asserting one. Also untested: the mirror image on receive-pack — a gunnar client pushing to a multi-pack peer ends in the same index_thin_pack call, so it may have the same problem, and nobody has measured it.