Module lfs 

git-LFS caching: proxy the batch API to upstream and cache objects on disk.

git-cache-proxy serves the git wire protocol (see git), but LFS objects use a different HTTP API: a JSON “batch” negotiation that hands back a per-object download URL, then a content-addressed GET of the object itself. Because clones are routed through the proxy, a client’s git-lfs derives its LFS endpoint from the proxy URL and talks LFS to us - so we must answer it, or every LFS-tracked file fails to check out.

Flow: POST /info/lfs/objects/batch -> forward to upstream, then rewrite every download href to point back here (<repo>/info/lfs/objects/<oid>) so the object fetch is cached. GET /info/lfs/objects/ -> serve from the on-disk cache (content-addressed by oid), or on a miss fetch it once (re-batch for a fresh authorized URL, download, verify sha256 == oid, store) then serve. Objects are immutable, so a cached object is never stale and is shared across every repo that references the same oid.

Structs

Lfs

LfsConfig

Enums

Outcome

Whether an object request was served from cache or fetched from upstream.

Constants

INCOMING_DIR

Reserved subdir of the LFS store holding in-flight downloads before their atomic rename into place. On the same filesystem as the final object so the rename is atomic; skipped by the eviction scan.