git

/git/<org>/<repo>

Upstream repos, cloned and served like the real thing

Point your client at it

bash

git clone http://HOST:10220/git/torvalds/linux

Replace HOST with your mirror’s address. Port 10220 is the server’s default.

Upstream: https://github.com
What is stored: Bare repositories on disk. No blob store, no catalog row.

How it works

There is no clever caching layer here: a mirrored repo is a real git clone --mirror sitting on disk, served by git's own git http-backend over smart-HTTP. Clone, fetch, shallow clone, and submodule resolution therefore behave exactly as they do against the upstream, because it is the same program answering.
A leading path segment matching a configured source selects that upstream; otherwise the whole path goes to the default.
self/<name> is not a mirror at all — it is served canonically by the forge, so self-hosted repos and mirrored ones share one URL space.
Alone among the backends it stores no blob: a git repository is its own storage format.

Things that have cost real time

Written down because they were paid for once already.

Dumb HTTP has no shallow capability, so git clone --depth 1 used to die outright. Serving through git http-backend fixed it. CocoaPods catches that error and retries non-shallow while npm does not — so "CocoaPods works through the mirror" was never evidence anything else would.

A mirror that clones is not automatically a mirror that resolves SUBMODULES. git upload-pack refuses a want for any object that is not a ref tip, and a submodule is pinned to a COMMIT — that is exactly the request every submodule makes. It only surfaces under --depth 1, which is why the mirror looked fine for a year. The CGI now sets uploadpack.allowAnySHA1InWant, through the environment rather than into each repo's config, so mirrors that already exist need no migration.