There's a git server, it's installed when you install git, and it really does work very well.
> every instance is a disposable cache that revalidates with one conditional GET. No database, no Redis, no gossip, no leader, no node identity.
Git famously doesn't use that either...? What is the point?
> "just put the repositories on NFS" failed at every large host that tried it
Yeah, that's a terrible idea. You can just host Git on a server or two. Where's the limit? How much does it scale to put a single 64 core server with a 10 gbit link on a local network and put ONLY git on it? Is that really that slow and bad? You can give it 20+ TB of RAID storage for VERY cheap. What is the limit you're hitting? 200ms ping to it from across the world? Is that the issue we're solving?
> walgit takes that as-is, and adds what a monorepo on small machines needs: serving refs and web pages for a repository whose packs will never fit on the instance (a remote reader over HTTP range requests), keeping commits and trees local while blobs stay in the bucket (the history pack), and moving clone bytes out of the server entirely (bundle-uri: fresh clones and catch-ups are static files the bucket or a CDN hands out).
So it's about monorepos that, for some reason, have blobs large enough to be impossible to serve via range requests, shallow clones, etc? Are people committing binary blobs of 1TB+ to their git? There's Git LFS, that hooks up an object store (like S3) to git for large files.
As an aside, I kind of adore that Tobi's latest post on his website, from 2019, talks about shopify's carbon emissions, meanwhile today his github is full of AI slop projects and enabling others to "vibe" even harder. He also missed that his clanker wrote an announcement post; https://github.com/tobi/walgit/blob/main/docs/announcing-wal...