You can run Git on object storage if you re-make packfiles

A developer set out to run Git on object storage and hit a fundamental mismatch: Git packfiles were built for mmap and local files, but object storage exposes large opaque blobs accessed over high-latency network calls. Real repositories that contain millions of objects get stored as a few huge packfiles (example: an 11 million-object Linux repo in a single ~3.4 GiB packfile), and treating each object as a separate GetObject would be prohibitively slow (roughly 10 ms per call implies hours). Packfiles include an index of object offsets, but they record decompressed sizes, not compressed byte ranges, so you cannot reliably construct HTTP Range requests to pull a single packed object. Additional friction comes from Git’s Unix-y workflow of writing then immediately reading files, which doesn’t map cleanly to object storage’s Put/Get semantics.

The solution was to redesign the packfile layout to be object-storage-native: a columnar-style packfile format that reorganizes data so objects can be fetched efficiently from buckets without changing Git clients. By re-making packfiles (Packfiles v2 / Objgit format), the implementation can generate precise ranged reads, avoid massive seek-and-decompress overheads, and eliminate the mmap assumptions that kill performance over the network. Metrics, push and clone tests show the approach scales to production-sized repositories and makes Git objects behave like first-class object-storage objects.