Back to all articles
BitTorrent's Creator Says Git Is Broken — 470 Lines of Python Prove It

BitTorrent's Creator Says Git Is Broken — 470 Lines of Python Prove It

Bram Cohen's Manyana uses CRDTs so merges never fail. With Jujutsu at 27K stars and agents making thousands of commits, Git's merge model is under siege.

Human-architected research synthesized with the assistance of AI personas.
Aether (AI)
18 min read
Git
Version Control
Crdt
Jujutsu
Developer Tools
Agentic Ai

✨TL;DR / Executive Summary

Bram Cohen's Manyana uses CRDTs so merges never fail. With Jujutsu at 27K stars and agents making thousands of commits, Git's merge model is under siege.

💡 TL;DR (Too Long; Didn't Read)

Key takeaways in 60 seconds:

  • Bram Cohen (creator of BitTorrent) just published Manyana — a version control proof-of-concept built on CRDTs where merges never fail. 470 lines of Python. Public domain. The conflict presentation alone is a generation ahead of Git's opaque <<<<<<< / >>>>>>> markers.
  • Jujutsu (jj) has quietly accumulated 27,000+ GitHub stars and a Google engineering team behind it. It wraps Git's storage layer with a radically better UX: working copy as a commit, no staging area, native undo, and a query language for commits called revsets.
  • The agentic stress test: Git was designed for humans making ~10 commits per day. Anthropic's compiler swarm made 100K+ lines of code with 16 agents. Cursor's FastRender threw 600 agents at a browser, generating 3,342 commits with an 88% CI failure rate. Git's three-way merge heuristic breaks under massively parallel agent workflows.
  • CRDTs are the natural fit for agent swarms: commutative merges mean order doesn't matter, deterministic results mean reproducibility is guaranteed, and generation counting handles the add/delete cycles that agents produce at machine speed.
  • Three philosophies are emerging: Manyana (CRDT-first, merges never fail), Jujutsu (UX-first, Git-compatible), and Pijul (theory-first, patches as first-class citizens). Git won't die — it'll become TCP/IP. The question is what wraps it.
  • Bottom line: If you're building agent orchestrators, study CRDTs. If you're a Staff+ engineer tired of git stash gymnastics, try jj on a side project this week. The future of version control isn't about replacing Git. It's about making it survive the agentic era.

The 21-Year Itch

In April 2005, Linus Torvalds was furious. BitKeeper had revoked the Linux kernel's free license, and a thousand developers suddenly had no version control system. Linus sat down and, in what remains one of the most impressive feats of rage-driven engineering, built Git in 10 days.

Git solved a 2005 problem brilliantly. Teams of 10 to 50 developers. Manual commits. Weekly merges. A branching model where humans could hold the entire dependency graph in their heads. The distributed philosophy that made every clone a complete repository was revolutionary — and it scaled beautifully for 20 years.

But 2026 is not 2005.

In February, Anthropic tasked 16 Claude Opus 4.6 agents with building a C compiler from scratch — 100,000+ lines of Rust, no dependencies, 99% pass rate on the GCC torture test suite. Around the same time, Cursor pointed 600 GPT-5.2 agents at building a web browser — 3,342 commits in 7 days, 1M+ lines of code, and an 88% CI failure rate. The agents weren't bad. The coordination infrastructure was.

When hundreds of agents commit in parallel, Git's three-way merge heuristic — a brilliant approximation designed for human-scale collaboration — starts producing catastrophic failures. Merge conflicts multiply combinatorially. CI pipelines choke. The test suite that was supposed to be the orchestrator becomes the bottleneck.

Git isn't broken. It's 21 years old, and the world changed under it.

This week, two projects landed on Hacker News that represent the most credible challenges to Git's merge model in a decade. One is a 470-line proof-of-concept from the creator of BitTorrent. The other is a Google-backed tool with 27,000 stars that your teammates won't even notice you're using.

Manyana: When Merges Never Fail

Bram Cohen doesn't need an introduction, but let's give him one anyway: creator of BitTorrent, one of the most elegant distributed systems protocols ever designed. He's been thinking about version control for at least 15 years (his LiveJournal posts from 2010 discuss merge algorithms), and he co-authored Codeville, an early attempt at a better VCS.

On March 22, 2026, Cohen published Manyana — a proof-of-concept for CRDT-based version control. The entire implementation is 470 lines of Python. It's public domain. And it contains ideas that will influence how we think about merging for the next decade.

The Core Insight

CRDTs — Conflict-Free Replicated Data Types — are a data structure from the distributed systems world that guarantees eventual consistency. The key properties: merges are commutative (merge(A, B) = merge(B, A)) and associative (merge(merge(A, B), C) = merge(A, merge(B, C))). Traditional version control systems approximate these properties with heuristics. CRDTs provide them as mathematical guarantees.

Verified SourceGitHub — bramcohen/manyana

Manyana's merge algorithm always produces a result. There is no failure case. But "conflict-free" doesn't mean "no conflicts worth showing to the user."

This is where every previous attempt at CRDT-based VCS stalled. If merges never fail, what does a "conflict" even mean? Cohen's answer is elegant: a conflict is surfaced when concurrent edits are too near each other — adjacent lines or lines separated only by whitespace. The merge still produces a deterministic result. But the user sees an annotated output that explains what each side did, not just what each side looks like.

The Delete-vs-Insert Problem

Consider the hardest case. Two developers branch from a file containing a function. One deletes the entire function. The other adds a logging line in the middle.

Git gives you two opaque blobs separated by conflict markers. You have to mentally reconstruct what happened. Manyana labels each section with the action and which side performed it: begin deleted left, begin added right, begin deleted left. You can see the structure of the conflict: left deleted the function, right inserted a line into the deleted region.

This isn't a cosmetic improvement. It's a fundamentally different model of conflict presentation — one that gives the reviewer enough information to make an informed decision without diffing the branches manually.

The Weave and Generation Counting

Under the hood, Manyana uses a weave — a single linear structure containing every line that has ever existed in the file, interleaved with metadata. Each line carries three pieces of information: depth (encodes the tree structure of insertions), anchor direction (whether a line was inserted above or below its neighbor), and a generation count (an integer that increments on each add/delete cycle — odd means present, even means deleted).

The generation count deserves attention because it solves the "local undo problem" that has tripped up every attempt at principled merge semantics. Cohen walks through a criss-cross case in his README that demonstrates why interpreting deletions as local undos leads to situations where a merged child looks like neither of its parents — a result that violates basic user expectations. Generation counting is simple, deterministic, and never produces these paradoxes.

The Cherry-Pick Trap

Cohen identifies three approaches to cherry-picking in a CRDT system, and explicitly calls two of them traps. Squashed patches can cause identical-looking code to merge into duplicated lines (a consequence of the structural history). Replaying exact patches works but is fragile. His recommended approach — marking a range of commits as "already applied" — is the cleanest but requires the system to track merge provenance.

This level of honesty about trade-offs is why the Hacker News and Lobsters discussions have been so substantive. Cohen isn't selling a product. He's publishing a coherent design document with 470 lines of executable proof.

Jujutsu: The Git You Wished You Had

If Manyana is a theoretical breakthrough, Jujutsu (jj) is the practical revolution already happening.

Created by Martin von Zweigbergk at Google in 2019, Jujutsu has accumulated over 27,000 GitHub stars, 11,000+ commits, and nearly 1,000 forks. Google uses it internally on some of the largest repositories in the world. It's written in Rust. And here's the critical detail: it uses Git's on-disk format. Your .git directory stays the same. Your teammates keep using git. Your CI/CD pipelines don't change. You just get a better interface.

What Jujutsu Fixes

The working copy is a commit. In Git, the working copy is a nebulous state that exists outside the commit graph. This is why git stash exists — you need to temporarily shelve uncommitted work. In Jujutsu, checking out a commit creates a new working-copy commit on top of it. Every edit is automatically part of the commit graph. git stash becomes unnecessary. "Error: Your local changes to the following files..." never appears.

Operations are immutable. Every action creates a new entry in an operation log. Made a mistake? jj undo. This isn't git reflog — a recovery mechanism that most developers don't know exists. It's first-class undo, baked into the core mental model.

Revsets. Jujutsu includes a query language for selecting commits. Want all commits by Alice that touch Python files? jj log -r "author(alice) & file(*.py)". This transforms commit navigation from "read a wall of text in git log" to "query a structured database." For anyone who has used advanced Git workflows, revsets feel like the feature Git should have had from the start.

No staging area. The index — Git's "staging area" — is one of the most confusing concepts for developers at every level. Jujutsu eliminates it entirely. Changes are tracked automatically. You describe your commit when you're ready, not when you git add.

The Honest Limitations

Jujutsu's ecosystem is young. IDE integrations are thin compared to Git's decades of tooling — though the JJK extension for VS Code and the jjui TUI are actively developing. GitHub's pull request workflow requires workarounds (bookmarks instead of branches). And the community, while passionate, is a fraction of Git's.

ReportedDEV Community — Jujutsu review, March 2026

For large organizations with deeply embedded Git workflows, CI integrations, and hundreds of developers, Jujutsu may not yet be ready. The Git compatibility layer means you can use it, but you'll hit edges where the abstraction gets thin.

But the migration story is compelling. Because Jujutsu reads and writes the same .git directory, adoption is individually incremental. One developer on a team can switch to jj without anyone noticing. If it doesn't work out, delete the .jj folder and you're back to pure Git. Zero risk.

The Agentic Stress Test

Here's where the gsstk perspective adds something nobody else is talking about.

We've spent the last two months documenting what happens when AI agents use Git as a coordination protocol. The results are stark:

Anthropic's compiler project used 16 agents with a flat, git-based swarm architecture. No central orchestrator — the test suite was the orchestrator. Result: 100,000+ lines of Rust, 99% pass rate on the GCC torture test. The key insight: with only 16 agents and a rigorous test suite, Git's merge model held.

Cursor's FastRender project used 600+ agents with a hierarchical planner/worker/judge pipeline. Result: 3,342 commits, 1M+ lines of code, an 88% CI failure rate, and a codebase that couldn't compile. The merge infrastructure buckled under the combinatorial explosion of parallel changes.

The pattern is clear: Git's three-way merge works at human scale and even at small-swarm scale (16 agents). It breaks at large-swarm scale (600 agents). The failure mode isn't Git's fault — three-way merge was never designed for this. It's a heuristic that assumes a manageable number of concurrent branches with limited overlap.

Why CRDTs Are Natural for Agent Swarms

CRDTs solve this by design:

Commutativity means order doesn't matter. When 600 agents are committing in parallel, the order in which their work gets merged is non-deterministic. With Git, different merge orders can produce different results (or different conflicts). With CRDTs, merge(A, merge(B, C)) always equals merge(B, merge(A, C)). The orchestrator doesn't need to enforce a canonical ordering.

Determinism means reproducibility. If two different orchestrators merge the same set of agent outputs, they get exactly the same result. This is critical for auditability — you can replay any merge sequence and verify the outcome.

Generation counting handles machine-speed add/delete cycles. Agents iterate much faster than humans. An agent might add a function, test it, delete it, rewrite it, and commit — all in seconds. Generation counting tracks this naturally without the complexity of tracking individual operations.

Jujutsu's operation log is audit infrastructure for free. Every jj operation creates an immutable log entry. When agents are making changes at machine speed, having a complete, queryable history of every operation — not just every commit — is exactly the kind of observability that the OWASP Agentic Top 10 recommends.

The deeper insight: agent orchestrators need a VCS that behaves like a database with eventual consistency, not a tool designed for human-scale optimistic locking. CRDTs bridge that gap.

The Landscape: Three Philosophies

The version control landscape beyond Git is richer than most developers realize. Three distinct philosophies are emerging:

Manyana: CRDT-First

Philosophy: Rebuild merge semantics from mathematically sound foundations. Merges never fail. Conflicts are informative annotations, not error states.

Storage: Weave-based, self-contained. The entire history of a file lives in one structure.

Maturity: Proof-of-concept. 470 lines of Python. No repository management, no network protocol, no CLI. This is a design document with executable code, not a product.

Agentic readiness: Highest in theory. Commutativity and determinism are exactly what swarm architectures need. But years away from production use.

The Pijul question: The Pijul version control system has been using CRDTs for merges since 2021, with a theory-first approach based on patch algebra. The Lobsters discussion immediately asked whether Cohen had reinvented Pijul. The answer is nuanced — Manyana and Pijul share the CRDT foundation but differ in conflict presentation and the specific data structures used. Cohen's contribution is primarily in the UX layer: how to surface meaningful conflicts in a system where merges are technically conflict-free. Still, anyone interested in Manyana should study Pijul's documentation. The cross-pollination between these projects will be more valuable than competition.

Jujutsu: UX-First

Philosophy: Don't reinvent storage. Git's object model is fine. Fix the interface.

Storage: Git's on-disk format, read and written directly. Full interoperability with Git repositories and hosting platforms.

Maturity: Production-ready for individuals and small teams. 27,000+ GitHub stars. Used at Google. Active development with regular releases (latest: v0.39+). Growing ecosystem of TUIs and VS Code extensions.

Agentic readiness: Moderate. The immutable operation log provides excellent auditability. Revsets enable programmatic commit queries. But the merge algorithm is still Git's under the hood — the UX improvements don't change the merge semantics.

Sapling: Scale-First

Worth a brief mention: Meta's Sapling is a fork of Mercurial with a Git backend, designed for massive monorepos. It solves the scale problem (Facebook's scale) but doesn't address merge semantics or agentic workflows. It's a power tool for a specific use case, not a general-purpose evolution.

Where This Is Heading

Git won't die. It's infrastructure — like TCP/IP, like POSIX. The .git directory will persist as a storage format and interchange protocol for decades.

The question is what sits on top of it. The most likely future:

Git as storage layer. Jujutsu-style tools as human interfaces. CRDT-based merge engines (Manyana's descendants) as agent coordination protocols. The three layers serve different stakeholders: Git gives you portability and ecosystem compatibility, jj gives you developer experience, and CRDTs give you the mathematical guarantees that swarm architectures demand.

What This Means for You

If you're a Staff+ engineer managing agent workflows: Start evaluating Jujutsu for your daily development. It's zero-risk (Git-compatible, individually adoptable) and the operation log alone will change how you think about commit history. Install it with brew install jj and run jj git init --colocate in an existing repo.

If you're building agent orchestrators: Study CRDTs. Read Manyana's README end-to-end — it's a masterclass in applied distributed systems theory. The eventual consistency model is how multi-agent coordination systems will handle code in production. Today's orchestrators use Git because it's there. Tomorrow's will use something that provides mathematical guarantees about merge determinism.

If you want to contribute: Manyana is 470 lines of public domain Python. It needs a real diff algorithm (Cohen explicitly calls out that Python's SequenceMatcher should be replaced with something like Git's histogram diff). Jujutsu needs IDE integrations — the VS Code extension (JJK) is actively developed. Both projects are small enough that a single experienced contributor can make meaningful impact.

If you're an engineering leader: The next time your team debates branching strategies, consider that the debate itself might be obsolete. When merges never fail, when working copies are commits, when every operation is undoable, the elaborate ceremonies around GitFlow and trunk-based development become less necessary. The tool should serve the workflow, not the other way around.

The future of version control isn't about replacing Git. It's about making Git survive the agentic era — the era where the bottleneck isn't how fast you can type git commit, but how fast 600 agents can coordinate on a codebase without stepping on each other.

Bram Cohen just showed us what the merge algorithm should look like. Martin von Zweigbergk already showed us what the interface should look like. The question is how long it takes the industry to put the pieces together.

This article was human-architected and synthesized with AI assistance under the Aether (AI) persona.

External Sources

Receive new articles

Subscribe to receive notifications about new articles directly to your email

We won't send spam. You can unsubscribe at any time.