Skip to content

fix(git): serve want-by-sha for unadvertised refs (PR merge commits) - #27

Open
DanielHabenicht wants to merge 1 commit into
rolandjitsu:mainfrom
DanielHabenicht:fix/pr-merge-ref-fetch
Open

fix(git): serve want-by-sha for unadvertised refs (PR merge commits)#27
DanielHabenicht wants to merge 1 commit into
rolandjitsu:mainfrom
DanielHabenicht:fix/pr-merge-ref-fetch

Conversation

@DanielHabenicht

Copy link
Copy Markdown

Before serving an upload-pack RPC, parse the client's want lines and, for any SHA missing from the mirror, fetch it from upstream on demand and pin it under a reserved refs/proxy-wants/<sha> ref. Pinning makes the object a valid want tip (so upload-pack serves it) and keeps it from git gc. The namespace is hidden from the ref advertisement (uploadpack.hideRefs) yet still honored as a want tip, and excluded from fetch --prune so pins survive periodic refreshes.

Relies on the upstream serving arbitrary SHAs (GitHub's allowAnySHA1InWant); an upstream that refuses leaves the request to fail as before - no regression. Ordinary branch/tag clones pay only a single cheap cat-file check, never an extra upstream call.

What kind of change does this PR introduce?

  • fix
  • feat
  • refactor
  • perf
  • docs
  • test
  • build / ci
  • chore

Summary

actions/checkout on a pull_request event fetches the synthetic merge commit by bare SHA. That commit lives only under GitHub's unadvertised refs/pull//merge, so clone --mirror never captured it and the mirror's upload-pack rejected the want with "fatal: not our ref ", breaking CI behind the proxy.

Tests

  • Added / updated tests (unit, plus integration where it fits)
  • Not relevant, because: ...

Checklist

  • CI is green locally: cargo fmt --all --check, cargo clippy --all-targets --all-features --locked -- -D warnings, cargo test --all-features
  • Commits follow Conventional Commits; AI-assisted commits carry an Assisted-by: trailer (see CONTRIBUTING.md / AGENTS.md)
  • Preserves the read-only, pull-only invariant (no push or proactive replication to upstream)
  • [-] Docs / README updated if behavior or flags changed

Breaking change?
If yes, describe the impact and the migration path (flags / env, on-disk cache layout).

actions/checkout on a pull_request event fetches the synthetic merge
commit by bare SHA. That commit lives only under GitHub's unadvertised
refs/pull/<n>/merge, so the mirror clone never captured it and
upload-pack rejected the want with "not our ref", breaking CI behind
the proxy.

Before serving an upload-pack RPC, parse the client's want lines and,
for any SHA missing from the mirror, fetch it from upstream on demand
and pin it under a reserved refs/proxy-wants/<sha> ref. Pinning makes
the object a valid want tip (so upload-pack serves it) and keeps it
from git gc. The namespace is hidden from the advertisement yet still
honored as a want tip, and excluded from prune so pins survive
periodic refreshes.

Relies on the upstream serving arbitrary SHAs (GitHub's
allowAnySHA1InWant); an upstream that refuses leaves the request to
fail as before, no regression. Ordinary branch/tag clones pay only a
cheap cat-file check, never an extra upstream call.

Assisted-by: Claude:claude-opus-4-8
Comment thread src/git.rs
//! upstream is only ever *pulled* from - nothing is pushed or replicated
//! proactively. A miss transparently pulls from upstream, so the cache is never
//! stale for the ref the client actually asked for.
//!

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me know If I should let claude turn the comments down

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant