// the take
walgit is a Rust git server that stores no state of its own — every repository is a write-ahead log of immutable packs in an S3 or GCS bucket, with a tiny CAS-rewritten manifest as the only commit point. It's an implementation of the architecture from Cursor's 'Git at any scale' post, aimed at teams who want to run git hosting (plus LFS, a web UI, and webhooks) without owning a database or a replication story.
The core trick — a compare-and-swap on one small manifest object replacing leader election and quorum — is real and genuinely eliminates the database most self-hosted git servers need; any replica can accept a push and the bucket decides who wins. It doesn't reinvent git's hard parts: upload-pack and repacking stay with the real git binary, and walgit only owns receive-pack and the ref/log plumbing, which keeps the riskiest, most-optimized code path (pack generation) out of a from-scratch reimplementation. The ObjectStore abstraction is backed by actual contract tests run against S3, GCS, memory, and local rustfs rather than just an interface with one implementation exercised. Shipping TLA+ specs with dozens of named failure-scenario configs (stale retries, ABA races, partial compaction) alongside a fault-injection simulation suite is a level of correctness effort you rarely see in a project this size.
The headline promise — serving repositories larger than the machine running it — is explicitly unfinished per the README's own packfile migration notes: protected (non-anonymous) repos and large-repo performance are still 'release gates,' so the thing that differentiates this from a normal git server isn't proven yet for real-world auth setups. receive-pack and pack ingestion (index-pack, connectivity checks) are reimplemented rather than delegated to git, which puts a young, independent implementation directly on the trust boundary for every incoming push — historically the area where git hosting services have had the worst security bugs. The whole consistency model rests on compare-and-swap semantics holding across whatever bucket you point it at, and 'S3-compatible' backends like MinIO, R2, or Ceph don't all guarantee conditional writes the same way S3 does, so the WAL's safety story is only as strong as your specific backend's actual behavior, not the idealized one in the spec. `auth.mode = "none"` gives every caller write and admin by default and is described as fine for 'loopback experiments' — an easy footgun if that config gets copied into a real deployment unchanged. There's also no built-in request router: scaling to multiple serve hosts means you bring your own layer to route by `/<owner>/<repo>`, which walgit doesn't provide.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →