Why it matters
Live clone routing lets Git use its normal Smart HTTP protocol while repository storage stays on independent mirrors. The selected mirror hostname is never exposed to the Git client, so links and remotes keep the stable ForkMesh URL.
Code disappears from a network when one hosted account, one VM, or one storage path becomes the only way to reach it. In ForkMesh, live clone routing addresses that need at the feature level, keeping the behavior close to the repository instead of buried in a detached hosted layer.
How ForkMesh handles it
Nodes register a Cloudflare-proxied HTTPS endpoint with an account-bound Ed25519 signature. Scheduled nonce challenges verify freshness, latency, identity, and a signed repository refs digest. For each request, the Worker chooses from the matching public repository group, creates a method/path/body-bound single-use capability, and streams the gateway response.
Clone stickiness keeps the related info/refs and upload-pack exchange on one origin. A failed origin is retried only within strict idempotent and response-safety bounds; the Worker never buffers repository content into permanent storage.
Where it fits
Use live clone routing when availability, clone routing, and preservation need to be handled by the mesh instead of by a single origin.
It pairs with the rest of Distributed hosting & preservation because Live clone routing keeps Git Smart HTTP requests routed to the node that actually serves the repository connected to the repository, its signatures, and the nodes that serve it.