01
walgit — a git host where the bucket is the repository and every server is cache
An MIT-licensed Rust git server, pushed to GitHub Saturday night by Tobias Lütke as "initial public release" and at 1,341 stars by this morning. You run one binary and point it at an S3 or GCS bucket; you get smart HTTP push and fetch, fresh clones served as static bundle-uri files from the bucket or a CDN, Git LFS, a browsing web UI, a JSON API with an SDK, per-repository push policy and webhooks. Every push is an immutable pack in the bucket plus a compare-and-swap rewrite of a tiny manifest; every read starts with one conditional GET, usually a 304. The README's line for it: "Kill them all and you lose warmth, nothing else." It is an implementation of Cursor's Git at any scale design — the system Cursor calls Continuity, published August 18 and not open-sourced — with the additions needed to serve a repository from machines smaller than it: pack indexes local and pack data read by HTTP range request, a derived history pack of commits and trees so only blob bytes cross the network, and bundles cut on calendar slots so a clone never touches the server. The reference workload in the repo's own manual is a 57 GiB, 73-million-object, 466,000-ref monorepo served from hosts whose disk is 20 GiB of tmpfs; the draft announcement claims CI's blobless sparse clone went from 35 minutes to 8 seconds.
The machine-facing docs are the primary docs here, which is the first thing our standing check noticed: GOAL.md and AGENTS.md are addressed to "everyone (humans and agents)" and say to read them before the README, and they are candid in the way that matters — the object-store cost model is stated (60–80 ms per GET), and the pre-1.0 rule is blunt: "We owe nothing to previous shapes of this system... delete the old shape in the same change." The thread was less kind. The top comment could not find the why ("There's a git server, it's installed when you install git"). Then Kelly Sommers read the lease code and posted this: "Walgit leans on S3 primitives but has classic distsys bugs. Tests pass cuz its memstore makes cond deletes. But w/ S3 it HEAD->compare->DELETE so stale owner can delete new lease. The code incorrectly says S3 lacks conditional DELs." Leases are, per the README, "the only cross-instance mutex." The repository has three commits; the third, a hardening PR merged at 02:28 UTC today, touches admin, ingest and runtime stalls, and nothing in the log references the lease path. Whoever wrote the code — the thread's "Tobi didn't write any of this" is an accusation, not a finding — the bug report is the thing to check before the star count.
Reach for it if you host a monorepo that no longer fits the machine serving it, or you want a git remote that any disposable box can serve for a fleet of agents fetching all day. It replaces the self-hosted git server whose disk is the thing you back up. Tradeoffs: three commits and five watchers behind 1,341 stars; no release binary — building needs Rust, protoc, Node 24 and pnpm, or Nix, or the Containerfile; an unfixed lease race reported by a distributed-systems engineer on day one, in the one mutex the design has; the object-store round trip is the price of the architecture, and the bundles, caches and history packs are where the complexity moved rather than where it vanished; no code review, issues or CI, by design; and two days old, pre-1.0, with a manual that promises to break shape without notice.