By ByteBot
Yesterday, East River Source Control named Martin von Zweigbergk — creator of Jujutsu (jj), the Git-compatible version control system with over 30,000 GitHub stars — as its Chief Technology Officer. The announcement is not a minor dev-tool story. ERSC is building a direct replacement for the Git server layer, and the timing is deliberate: GitHub’s own COO disclosed the platform is now processing 275 million commits per week — a 14× year-over-year increase driven almost entirely by AI agents. Git is starting to show its age. ERSC is betting they know what comes next.
AI Agents Are Breaking Git’s Architecture
The numbers are difficult to dismiss. In all of 2025, GitHub handled 1 billion commits. By early 2026, the platform was processing 275 million commits every single week — on pace for 14 billion for the year. AI agent-generated pull requests went from 4 million in September 2025 to 17 million by March 2026, a 4× jump in six months. GitHub Actions compute minutes hit 2.1 billion in a single week in 2026, up from 500 million weekly in 2023. GitHub COO Kyle Daigle put it plainly: “There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year.”
The problem is architectural, not just operational. Git’s merge-to-main throughput caps at roughly 2 to 3 operations per second under standard configurations — a ceiling that was irrelevant when humans were the only agents committing code. At 275 million commits per week, that limit stops being an edge case and becomes a daily operational constraint. Servers built for human-scale usage are now absorbing agent-scale traffic, causing the repeated outages and performance degradation that teams have started noticing. Amplify Partners, who back ERSC, described the dynamic precisely: “Everything that makes Git frustrating now gets more pronounced as the volume increases. Git’s merge throughput ceiling is still there.”
The Local Fix Is Not Enough
Jujutsu has been solving Git’s client-side problems for years. It eliminates the staging area entirely — every working-copy state is a valid commit. It treats conflicts as first-class data structures rather than blocking error states, so agents can continue committing while conflicts exist and resolve them later. It provides a comprehensive undo system via operation logs, making rebases safe enough that developers finally use them. These are real improvements. But von Zweigbergk, who spent 15 years at Google building and maintaining this system, is clear about where jj ends.
“Jujutsu improves the part of version control that sits on your laptop. But the remote server is still Git, which has a ceiling that comes fast for products at scale. We think the storage layer has to change to match the model, and that work can be better supported by a company than an open source project.”
— Martin von Zweigbergk, ERSC CTO, Jujutsu creator
That distinction matters. jj is excellent — ByteIota covered its technical strengths in depth earlier this year, including the megamerge workflow, change IDs that survive rewrites, and the undo log that makes rebasing routine rather than dangerous. However, when the remote is still a Git server, jj inherits Git’s infrastructure ceiling. ERSC is going after the server itself.
Related: Jujutsu Version Control: Git-Compatible VCS with Megamerge
What ERSC Storage Ships in Private Beta
ERSC Storage enters private beta later this September. The core value proposition: thousands of commits per second versus Git’s 2 to 3, instant checkouts, support for arbitrarily large files, first-class conflicts at the storage level, and fine-grained per-directory ACLs that enterprise teams have needed for years but Git’s open-source model never prioritized. Stacked diffs code review is on the roadmap. Critically, ERSC Storage speaks both Git and Jujutsu protocols, so existing tooling points at it without requiring a migration project.
This is the strategic bet that matters: compatibility as adoption infrastructure. You do not choose ERSC instead of Git — you run your existing Git workflows against ERSC and unlock new capabilities incrementally. CEO Benjamin Brittain framed von Zweigbergk’s hire accordingly: “The hard problems many engineering teams are just beginning to face are ones he’s already been working on for over a decade.” ERSC is not starting from scratch; it is hiring the person who already built the model they are productizing.
Why This Is Not Mercurial
The comparison arrives reliably whenever a Git alternative appears: Mercurial was technically superior and nearly universally ignored. The Hacker News thread on von Zweigbergk’s hire (177 points, 138 comments) raised it within minutes. The structural answer is different this time. Mercurial required teams to migrate away from Git entirely — separate tooling, separate ecosystem, full commitment from every contributor. jj uses Git as its backend storage. Run jj git init --colocate in any existing repository, and jj and Git share the same .git directory. Your teammates do not need to change anything. You can adopt it tomorrow with zero coordination.
ERSC’s approach extends this logic to the server. Steve Klabnik, also at ERSC, clarified the community split in the HN discussion: the developers who say “five git commands cover everything I need” are not wrong — at their current scale. ERSC is targeting organizations where AI agents are generating the kind of commit volume that makes Git’s ceiling a daily operational reality. That cohort is expanding, not contracting.
Key Takeaways
- GitHub is processing 275 million commits per week in 2026 — a 14× increase from 2025 — with AI agents responsible for most of the growth. Git’s merge throughput ceiling is becoming an operational problem, not an edge case.
- ERSC’s thesis is precise: jj fixes the client; the server still needs to change. Martin von Zweigbergk — the most credible person to make this argument — is now building that server.
- ERSC Storage (private beta September 2026) targets thousands of commits per second, instant checkouts, first-class conflicts, and fine-grained ACLs — all with full Git backwards compatibility.
- The Mercurial comparison misses the key structural difference: jj works alongside Git in the same repository, requiring no team coordination and no migration.
- Try jj locally today with
jj git init --colocatein any existing repo. Request ERSC early access if you are hitting Git’s limits at scale.
