Commissioned, Curated and Published by Russ. Researched and written with AI.
What’s New This Week
First publication. No prior updates.
Changelog
| Date | Summary |
|---|---|
| 22 Mar 2026 | Initial publication. |
Bram Cohen – the person who created BitTorrent – published Manyana on March 22, 2026. It’s a ~470-line Python demo. It hit 338 points on HN the same day. The code is public domain.
The demo is small. The idea is not.
The merge failure problem
Every engineer who has used git has hit a merge conflict that blocks progress. You can’t merge until you resolve it. That’s not a law of physics – it’s a consequence of how 3-way merge works. It needs a common ancestor to compute diffs against. When branches have diverged enough, or when the merge topology gets complex (think: aggressive rebasing creating histories with no single common ancestor), 3-way merge breaks down.
Bram’s argument is that this is an artifact of the data structure, not an inherent property of version control. Switch to a CRDT – a Conflict-Free Replicated Data Type – and merges cannot fail by definition.
That’s the whole thesis. Merges that cannot fail, ever, with better conflict presentation on top.
The conflict display
The current state of the art for “one person deleted a function, another added a line inside it”:
<<<<<<< left
=======
def calculate(x):
a = x * 2
logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> right
Two opaque blobs. You have to mentally reconstruct what each side actually did. Left deleted the function. Right added a logging line inside it. You can’t see that from the output – you have to infer it by knowing what the file looked like before.
Manyana’s output for the same conflict:
<<<<<<< begin deleted left
def calculate(x):
a = x * 2
======= begin added right
logger.debug(f"a={a}")
======= begin deleted left
b = a + 1
return b
>>>>>>> end conflict
Each section is labelled with what happened and who did it. You can see the structure: left deleted a function, right inserted a line in the middle of it. The conflict display describes the conflict instead of just showing two outcomes and making you figure it out.
This alone is worth attention. It’s a better UX than what git produces, and it doesn’t require a CRDT to implement – but the CRDT is what makes it possible to have this display without blocking the merge.
The CRDT properties
History lives in the weave. The core data structure is a “weave” – a single structure containing every line that has ever existed in the file, with metadata about when it was added and removed. Merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one comes out, always correct. The history is embedded in the data, not reconstructed from it.
Line ordering is permanent. When two branches insert code at the same point, the CRDT picks an ordering and it sticks. This prevents a class of problem where conflicting sections are both kept but resolved in different orders on different branches – a case where 3-way merge can produce inconsistent results depending on which branch you merge into which.
Merge order doesn’t matter. Any order of merging branches produces the same result. This is the commutativity property. Multiple engineers merging the same set of branches independently all arrive at the same final state. With 3-way merge, the order can matter.
Non-destructive rebase. Conventional rebase rewrites history – your commits appear to have happened on top of the latest main, but the actual history is destroyed. In Manyana’s model, you can replay commits onto a new base while keeping the full history intact. The only addition needed is a “primary ancestor” annotation in the DAG. This matters most when aggressive rebasing creates merge topologies with no single common ancestor – exactly where 3-way merge breaks down. CRDTs don’t care, because the history is in the weave.
The timing problem
Bram doesn’t mention AI agents. He doesn’t need to – but the timing is notable.
Claude Code, Cursor, and similar tools can now write code faster than humans can review it. The natural next step – which is already happening – is multiple AI agents working on the same codebase simultaneously. Five agents committing to the same repo on different feature branches, all moving faster than any human review cycle.
That’s exactly the concurrent edit pattern CRDTs are designed for. Merge conflicts that were a minor friction for human developers become a genuine bottleneck when agents are committing in parallel at machine speed. The human review cycle that historically smoothed over merge conflicts doesn’t exist in the same way when the agents are the ones doing the work.
The problem Bram is solving was already worth solving. It’s about to become more acute.
Honest current state
Manyana is a demo. 470 lines of Python, operating on individual files. Cherry-picking and local undo are not yet implemented (the README describes how they’d work). Non-destructive rebase is specified but not built.
Bram describes it as a proof that CRDT-based version control can handle the hard UX problems and come out with better answers. That’s an accurate description of what it is. It is not a replacement for git. Turning this into a production VCS would require serious engineering – distributed storage, performance at scale, editor integrations, tooling across the entire ecosystem.
But the conceptual argument is sound. CRDTs eliminate merge failures not by being clever about conflict resolution, but by operating on a data structure where “failed merge” isn’t a valid state. The conflict display improvement is demonstrably better. The demo proves the UX works.
Whether anyone builds the production version is a separate question. The answer to “can CRDTs solve version control’s hardest problems?” appears to be yes.
Source: bramcohen.com/p/manyana / github.com/bramcohen/manyana