East River Source Control charts a post-Git path with custom storage and Jujutsu

East River Source Control, a company that has stayed quiet for most of its first year-plus of existence, has laid out its thinking on where version control goes next. In a blog post titled "What Comes After Git," dated September 10 and later surfaced on Hacker News's front page, the firm argues that Git's design is showing its age and explains the architecture it has built in response: a service that speaks the Git protocol to ordinary clients but stores code in a purpose-built engine rather than in Git repositories. There is no product announcement in the post — the company says one is coming soon — which makes the piece mainly a statement of direction from a new entrant in a market long dominated by hosting built around Git.

Agents are reshaping the workload

According to the post, the sharpest pressure on version control today comes from agentic development. Teams working with AI agents generate changes far faster than before, which inflates repository sizes, multiplies active branches and creates heavy contention when work is merged. Agents also tend to work best with monorepos, since having more context in one place is easier for them to consume, and they are pulling development environments into the cloud, where fast clone times become essential. The company's summary is that problems once confined to the very largest engineering organizations are now arriving at ordinary teams' doors.

The protocol stays, the storage goes

The architectural heart of the post is a comparison of two setups. A typical Git host, the company writes, places a serving layer in front of Git repositories stored on disk. ERSC instead terminates the standard Git protocol in a bridge that talks to a custom, non-Git storage engine; it also exposes a GraphQL API that the post's simplified diagram leaves out. The claimed payoff is horizontal scalability that architectures keeping an actual Git repository as their canonical store cannot match, plus isolation: each deployment is separate, so one customer's usage cannot degrade another's.

The case against Git itself rests on history. It was created in 2005 around the needs of the Linux kernel, an open-source project, which the company says left it without features that organizations want when their code is not public. Scale is the other argument: the post cites roughly 43 million lines of code for the kernel's 7.2 release, while some companies have run monorepos measured in billions of lines for years. Yet the firm is candid about network effects — tooling across the industry assumes Git, and contemporaries such as Mercurial and Bazaar lost out to that gravity. Hence the compromise: keep the protocol as a compatibility surface and replace everything behind it.

Jujutsu as the second on-ramp

For teams that eventually outgrow the Git protocol itself, ERSC points to Jujutsu, the version control system usually abbreviated as jj. The company says it admires jj's incremental adoption model: jj is a system in its own right but can target multiple backends, most commonly a local Git repository, and Google maintains a backend for its internal Piper system. That lets an individual developer switch to jj while colleagues keep using git, because the server simply sees another Git protocol client. ERSC wants to mirror that pattern on the server side, with the same storage engine eventually speaking a native jj protocol alongside Git's.

The caveats are explicit. Upstream jj has no native protocol today, the work is future rather than current, and the company does not claim the jj project wants one. It says it would develop any such protocol with the community, document it fully and open-source any client modifications needed to support it.

The post closes by acknowledging that storage is only part of what teams need around code, pointing to code review, CI and issue tracking, and predicting an era of more customizable collaboration software rather than the all-in-one packages traditional forges have offered.

Why it matters

Version control is among the most conservative corners of developer infrastructure — organizations treat source code as too precious to migrate casually — so a strategy that preserves the Git protocol while swapping the engine underneath is a serious attempt to lower adoption risk. The post is also a data point in the debate over how AI agents change infrastructure requirements: if repositories, branch counts and merge pressure keep growing at the pace the company describes, the scaling limits of conventional Git hosting become a live question rather than a theoretical one. And the Jujutsu proposal, however hedged, raises the possibility of protocol-level competition beneath Git's familiar interface, with ERSC positioning itself as a would-be contributor to the jj ecosystem rather than a fork of it. None of this is shipping yet; the real test arrives with the announcement the company says is coming.