A Coherent Vision for the Future of Version Control

Git's heir or déjà vu? Devs feud over 'no-conflict' merges

TLDR: Bram Cohen released Manyana, a tiny demo showing conflict-free merges with clearer conflict views. The crowd split: some cheer a Git upgrade, others demand credit for Pijul and Codeville, and skeptics worry “never-failing” merges hide real problems—raising big questions about how we’ll collaborate on code next.

Bram Cohen dropped a tiny demo called Manyana—a 473‑line Python experiment claiming a cleaner future for version control with CRDTs (a way to merge edits that never technically fails). He shows off conflicts that explain themselves instead of dumping mystery blobs, and teases rebasing without rewrite nightmares. The community? Instant fireworks. Old‑schoolers like bos say it’s a revival of early 2000s ideas like Codeville’s “weave,” while fans cheer, “Finally, something better than Git!” and share the link like it’s contraband.

Then the credit war exploded: ZoomZoomZoom fires off that “CRDT for version control” isn’t new—hello, Pijul!—calling out the post’s vibe as conveniently forgetful. Skeptics like radarsat1 ask the uncomfortable question: if merges never fail, do we miss real, meaning-level conflicts that should stop you? Meanwhile, simonw gawks that it’s under 500 lines, sparking memes like “Git, but make it vibes” and “Hello World for version control.” Enthusiasts rave about better conflict displays; cynics mutter about network effects—Git’s gravity well doesn’t let you leave easily. TL;DR of the mood: fresh idea, fierce déjà vu, and a fight over who did it first.

Key Points

  • Manyana is a public-domain demo (~470 lines of Python) showcasing a CRDT-based approach to version control.
  • CRDT merges never fail; conflicts are flagged when edits interact, providing structured, informative conflict markers.
  • The design ensures deterministic line ordering across merges, preventing divergent resolutions across branches.
  • History is stored in a “weave” structure containing all lines and their add/remove metadata, eliminating the need for ancestor-finding or DAG traversal during merge.
  • A rebase model is proposed that preserves full history by replaying commits with a “primary ancestor” annotation, avoiding issues with aggressive rebasing.

Hottest takes

"We really do need an improvement over git; the question is how to overcome network effects" — logicprog
"Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it" — ZoomZoomZoom
"Is it a good thing to have merges that never fail?" — radarsat1
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.