Your Git repo has a dirty working directory, three files staged by accident, and a stash you are afraid to pop. Now imagine a version control system where none of those concepts exist. That system just got a serious vote of confidence: its creator walked out of Google to become CTO of a startup built around it.
On September 1, East River Source Control (ERSC) announced that Martin von Zweigbergk, creator of Jujutsu (usually shortened to jj), joined the company as Chief Technology Officer. Per the official announcement, he will lead engineering on ERSC's next generation version control platforms while remaining a core maintainer of jj as an open source project under the Apache 2.0 license.
I have not shipped jj on a work project, so treat this as a researched comparison, not a war story. Everything below comes from the ERSC announcement, the official Jujutsu documentation and GitHub repo, and the maintainer discussion on Hacker News, all linked inline.
Who is Martin von Zweigbergk and why should you care
If you have never heard the name, you have probably used his work anyway.
- He worked on Git itself. Before Jujutsu, von Zweigbergk contributed to Git, the tool used by 96% of professional developers according to the 2022 Stack Overflow survey that ERSC's announcement cites.
- He built Fig at Google, a Mercurial client that gave Google engineers a distributed workflow on top of Piper, the monorepo holding most of the company's code.
- He started jj as a side project in late 2019, and it grew into his full-time job at Google. The project now has more than 30,000 stars on GitHub, and the core team uses jj to develop jj on GitHub itself.
So when this particular person says the storage layer under every repo needs to change, it is worth 10 minutes of your attention.
What Jujutsu actually is
Jujutsu is a Git-compatible version control system written in Rust. Compatible is the key word: jj uses your existing Git repositories as its storage backend. Your remotes, your GitHub hosting, your CI pipelines, your teammates using plain Git, all keep working. Only commits and files live in Git; higher-level metadata like branches (called bookmarks in jj) sits in separate storage.
That design choice is the whole onboarding story. Adopting jj is not a migration. You run jj commands inside the same clone you already have.
The differences are conceptual, and the official Git comparison doc lists them clearly. The big ones:
- The working copy is a commit. jj automatically snapshots your working directory as a real commit, amended on every change. There is no staging area and no stash, because commits are the only visible object and they subsume both.
- No index. Workflows that depend on staging get modeled with actual commits instead, and jj has strong support for moving changes between commits.
- Conflicts are first-class. Merge conflicts are recorded inside commits instead of blocking every command. You can commit a conflict, rebase it, resolve it later, and the resolution propagates to descendants. Git treats conflicts as textual diffs; jj stores them as objects.
- Automatic rebasing of descendants. Rewrite a commit and everything on top of it, including your working copy and affected bookmarks, rebases automatically.
- An operation log with undo. Every operation on the repo is recorded, so "what just happened?" and "undo that" are real commands, not archaeology.
If you have ever lost an evening to a botched interactive rebase, the conflict and undo models alone explain why jj has a fanbase.
Why the ERSC move matters more than a normal job change
Startups hire prominent engineers all the time. This one is different for three reasons.
- The founder is Eric Sink lineage. ERSC (East River Source Control, backed by Amplify Partners, launched 2025) is building what it calls the next generation of version control platforms "for humans and machines". Hiring the jj creator as CTO, not as an advisor, means the open source project and the commercial platform share a technical direction.
- The funding trail is visible. A Renovate bot discussion on GitHub shows ERSC quietly opened preview access to a new forge, and teams are already asking about tooling support. ERSC Storage enters private beta this month per the announcement.
- The maintainer community is healthy, not captured. When the news hit Hacker News, maintainers pushed back on overhyped framing directly: jj does not "belong" to ERSC or Google, it is a community project, and most contributors have nothing to do with either company.
That last point addresses the obvious worry. If your tool's creator goes corporate, does the tool go corporate? The jj maintainers are explicitly saying no, and the Apache 2.0 license is the real guarantee.
The honest tension in von Zweigbergk's own words
The sharpest part of the announcement is a quote that jj users should read twice:
"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."
Parse that carefully. The creator of the most credible Git alternative is saying jj's local improvements are not enough. The server side, where Git holds most enterprise-scale pain, needs a storage layer that Git cannot become. And building that needs a company, because open source projects are bad at selling infrastructure.
That is also the strategic risk for jj itself. If ERSC's platform becomes the place where jj's server-side story lives, the project's center of gravity shifts from community to company. The maintainers deny it today. Watch whether core decisions stay on the public repo over the next year.
Jujutsu vs Git: a decision guide
Because jj wraps Git rather than replacing it, this is not a switch decision. It is a "who drives" decision.
- Use jj on top of Git if: you do stacked changes, heavy rebasing, or conflict-prone merges; you have lost work to rebase mistakes and want the operation log; you hate the staging area and never wanted it; you work on a monorepo or large repo where jj's rewrite performance helps. Your Git-hosting workflow is untouched.
- Stay on plain Git if: your team's shared vocabulary is Git and retraining is not free; your tooling and hooks assume Git plumbing; you are content and the friction is not costing you real hours. Git is not going anywhere, and 96% professional adoption means every answer is a search away.
- Watch, do not adopt, if: you are evaluating where source hosting itself is heading. ERSC's forge and storage bet is the interesting part, and it is a private beta, not a product.
One concrete suggestion if you try jj: run it on a personal project first, in colocated mode with your existing Git repo. The working-copy-as-commit model flips several Git reflexes, and it clicks faster when nothing is at stake.
The bigger picture: version control is being rethought in 2026
The jj story is not happening in isolation. Git is 20-plus years old and was designed for humans committing a few times a day. AI agents commit hundreds of times an hour, generate conflicts at machine speed, and need history that machines can query and undo. ERSC's tagline, platforms "for humans and machines", is aimed directly at that shift.
That is why a version control startup got funded and hired this team now. Whether jj becomes the local interface of that future or just its stepping stone, the next two years of source control will be more interesting than the last ten.
I write about developer tools, AI infrastructure, and the engineering practices around them every week. Subscribe, it is free, and it helps you keep up with shifts like this one before they hit your stack.
Have you tried Jujutsu, or do you think Git is unkillable? What was your experience? I read every comment.
If you found this useful, save it for the day your team debates version control tooling. The decision guide above is the takeaway.
Top comments (0)