Manyana - by Bram Cohen - Bram’s Thoughts

Bram’s ThoughtsSubscribeSign inManyanaA Coherent Vision for the Future of Version ControlBram CohenMar 22, 2026112ShareI’m releasing Manyana, a project which I believe presents a coherent vision for the future of version control — and a compelling case for building it.It’s based on the fundamentally sound approach of using CRDTs for version control, which is long overdue but hasn’t happened yet because of subtle UX issues. A CRDT merge always succeeds by definition, so there are no conflicts in the traditional sense — the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails. This project works that out.Better conflict presentationOne immediate benefit is much more informative conflict markers. Two people branch from a file containing a function. One deletes the function. The other adds a line in the middle of it. A traditional VCS gives you this:<<<<<<< left
=======
def calculate(x):
a = x * 2
logger.debug(f"a={a}")
b = a + 1
return b
>>>>>>> rightTwo opaque blobs. You have to mentally reconstruct what actually happened.Manyana gives you this:<<<<<<< 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 conflictEach section tells you what happened and who did it. Left deleted the function. Right added a line in the middle. You can see the structure of the conflict instead of staring at two blobs trying to figure it out.What CRDTs give youCRDTs (Conflict-Free Replicated Data Types) give you eventual consistency: merges never fail, and the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently. That one property turns out to have profound implications for every aspect of version control design.Line ordering becomes permanent. When two branches insert code at the same point, the CRDT picks an ordering and it sticks. This prevents problems when conflicting sections are both kept but resolved in different orders on different branches.Conflicts are informative, not blocking. The merge always produces a result. Conflicts are surfaced for review when concurrent edits happen “too near” each other, but they never block the merge itself. And because the algorithm tracks what each side did rather than just showing the two outcomes, the conflict presentation is genuinely useful.History lives in the structure. The state is a weave — a single structure containing every line which has ever existed in the file, with metadata about when it was added and removed. This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct.Rebase without the nightmareOne idea I’m particularly excited about: rebase doesn’t have to destroy history. Conventional rebase creates a fictional history where your commits happened on top of the latest main. In a CRDT system, you can get the same effect — replaying commits one at a time onto a new base — while keeping the full history. The only addition needed is a “primary ancestor” annotation in the DAG.This matters because aggressive rebasing quickly produces merge topologies with no single common ancestor, which is exactly where traditional 3-way merge falls apart. CRDTs don’t care — the history is in the weave, not reconstructed from the DAG.What this is and isn’tManyana is a demo, not a full-blown version control system. It’s about 470 lines of Python which operate on individual files. Cherry-picking and local undo aren’t implemented yet, though the README lays out a vision for how those can be done well.What it is is a proof that CRDT-based version control can handle the hard UX problems and come out with better answers than the tools we’re all using today — and a coherent design for building the real thing.The code is public domain. The full design document is in the README.Subscribe112ShareDiscussion about this postCommentsRestacksJustin D Kruger 1hLiked by Bram CohenFirst Bram, I love that you are working on this. Git has been in the wild for over a decade, and version control could use some fresh thinking. Especially, some challenging ideas.I plan to try to digest this for a bit, it's not 100% clear how this will work all of the time. I'd like to seem more examples, to fully understand it. Merges never failing do not yet make sense to me. I can only see your solution as a merge being a super position of commits.I love the idea of improving rebasing, and you seem to be on a good path. On my current personal project I've started to use feature branches, and then merge to an intermediate branch that mirrors main, so that merge conflict resolution occurs on the intermediate branch, and then i merge ff-only back to main. this preserves history, doesn't use a squash, and keeps main with clean stable only commits.My 3 largest version control pain points are:* angenic coding - wip commits tend to have more changed lines of code, by a few orders of magnitude. the commit message, and the commit size are not well summarized or understood. code agents can refactor like a beast given the right prompt for hours at a time. I once switched from react to svelte in a few prompts.* left vs. right code ancestries always seem to confuse me. rather than ordinal, I'd prefer logical assignment. which branch is left, which branch is right? who(blame)'s branch is left, who's branch is right? what commit message is left & right?* binaries - git works with lines of code only, and also only well with 'pretty' code. if your code has syntactic sugar, is compressed, or is a binary, then git breaks down quickly.compiled javascript that is all on one line of code is almost pointless to store in git. one statement per line works best, but if you define multiple vars, or a longer anonymous object or anything with any degree of complexity, then git treats the whole line as a change. then you have to compare A & B between the two lines and physically notice what changed. Some IDEs will show you sub token changes between the two lines, most wont.in the era of angenic coding, imagine a pull request where two complex lines look identical, but to the human it looks like only one variable name was added or removed -- but to the machine or hacker one of the characters in one of the other variables where changed to an international character to go undetected. in this case you could sneak in a change on one of the other variables and switch code behavior unexpectedly.on the binary front it would be cool, if version control software could become 'token' aware in much the same way of how LLMs are now first tokenizing input and output. tokens could be full variable names, or part of variable name (camel case, snake case, etc..).maybe the version control software supports tokenizer plugins, or maybe it supports file type plugins for binaries?maybe the version control has plugins for different languages, pdfs, bitmaps, jpgs, videos?I've also been thinking of what I love about Resilio Sync, and what feels missing from it. Version Control seems like something that I both miss, and conflicts with Resilio Sync, Dropbox, and other file sync solutions.Nothing really works well at both file sync across teams and version control for most files. File Sync solutions seem to conflict with git, and git doesn't work well with binaries.ReplyShare1 reply by Bram Cohen1 more comment...TopLatestDiscussionsNo postsReady for more?Subscribe© 2026 Bram Cohen · Privacy ∙ Terms ∙ Collection notice Start your SubstackGet the appSubstack is the home for great culture

This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts

Manyana: A Coherent Vision for the Future of Version Control – Bram Cohen

Bram Cohen’s “Manyana” project represents a significant rethinking of version control systems, grounded in the utilization of Conflict-Free Replicated Data Types (CRDTs). The core aim is to address long-standing UX issues within traditional version control systems like Git, proposing a fundamentally more robust and informative approach. Cohen’s argument centers around the inherent success of CRDT merges—they always succeed, regardless of the order in which branches are combined, eliminating the traditional conflicts and ambiguities that plague current systems. This success isn’t simply coincidental; it yields a system that identifies changes as conflicting when they intersect, presenting conflict markers that are far more informative than the opaque “blops” characteristic of Git.

The immediate benefit highlighted by Cohen is dramatically improved conflict visualization. Consider a scenario where two developers branch from a shared file containing a function. One developer deletes the function, while the other subsequently adds a line of code in the middle. A standard version control tool presents these changes as distinct, potentially confusing “<<<<<<< left” and “=======” blocks. Manyana offers a more granular representation: “<<<<<<< begin deleted left” and “======= begin added right,” clearly delineating the specific actions taken by each branch. Moreover, it provides context: “Left deleted the function. Right added a line in the middle.” This structured presentation significantly reduces the cognitive load associated with resolving conflicts.

The underlying principle driving Manyana is the nature of CRDTs. They offer eventual consistency—merges never fail, and the resulting state is uniform across all branches. This has profound implications for the design of a version control system. Line ordering predictably becomes permanent, preventing issues that arise when conflicting edits are resolved in different orders. Conflicts are treated as informational signals, surfacing only when changes occur “too near” one another, rather than blocking the merge process. Crucially, the system tracks *what* each individual side did, providing genuinely useful conflict presentation, unlike purely outcome-based systems.

Cohen describes the resulting state as a “weave”— a single structure containing every line ever present in the file, along with metadata detailing when each line was added and removed. This eliminates the need to reconstruct the history from a fragmented, directed acyclic graph (DAG). The merge process simply takes two states and produces a single, correct result. This design elegantly sidesteps the notorious “rebase nightmare” inherent in traditional Git, where rebasing can irrevocably alter history and create merge topologies lacking a clear common ancestor. In Manyana, the history remains embedded within the “weave,” accessible without reconstructing the DAG.

Cohen articulates a vision for a reimagined rebase process, suggesting that the effect of replaying commits onto a new base can be achieved without destroying the full history. This is facilitated by adding a “primary ancestor” annotation to the DAG. This approach contrasts sharply with conventional rebasing, which often results in chaotic, multi-way merge topologies.

Manyana is currently a demo project—approximately 470 lines of Python—designed to demonstrate the feasibility of CRDT-based version control. While feature-rich cherry-picking and local undo aren’t yet implemented (though the design document outlines a potential approach), Cohen emphasizes that the core design successfully tackles significant UX challenges, offering a superior solution compared to existing tools. The code is in the public domain, accompanied by a detailed README outlining the full design.

The system isn’t intended to completely replace Git, but rather to represent a viable alternative, particularly for scenarios where robust conflict management and a seamless merge experience are paramount.