The future of version control

Original Article ↗ Hacker News Discussion ↗

A new prototype from Bram Cohen explores using CRDT-based data structures and “weave”-style histories to build a version control system where merges always succeed and conflicts are surfaced as richer, more informative views of overlapping changes rather than hard failures. Commenters contrast this approach with Git and newer tools like Jujutsu and Pijul, debating whether CRDTs meaningfully improve real-world pain points such as merge UX, long-lived branches, and rebases, or whether they simply shift semantic conflicts into a different form. Many also argue that the future of version control may depend more on semantic/AST-aware tooling, better handling of large and binary files, and AI-assisted conflict resolution than on replacing Git’s underlying model outright.

CRDTs as a basis for version control

  • Many commenters like the idea of CRDT-based VCS and “weave”-style storage, noting prior systems (SCCS, Codeville, Darcs, Pijul) explored related ideas.
  • Others stress “CRDT” is a framework, not a single algorithm; trivial CRDTs like last‑write‑wins would be useless for code.
  • Several point out CRDTs guarantee convergence but not semantic correctness; they solve system-level conflicts, not intent-level ones.

Merges, conflicts, and UX

  • Many see current Git conflict UX (“ours/theirs”, opaque markers, blocking merges) as a real pain point.
  • The proposed “merges never fail, conflicts are just annotations” idea is compared to Jujutsu and Pijul, which store conflicts as first-class and allow deferring resolution.
  • Supporters say this avoids getting stuck mid-rebase and prevents re-resolving the same conflict; skeptics worry it just pushes broken code downstream.
  • Multiple people note Git already has better conflict styles (diff3/zdiff3) and powerful 3/4‑pane merge tools; they argue the core issue is tooling/UX, not Git’s data model.

Comparison to existing alternatives

  • Pijul is repeatedly raised as an existing CRDT-ish VCS with patch theory and easier cherry-picking/rebasing, but some report reliability and documentation issues.
  • Jujutsu is praised for history-preserving rebases, first-class conflicts, and easy Git interop; several say it already solves many of the problems described.
  • Some argue any new VCS must layer over or interoperate with Git due to network effects and tooling.

Scalability, binaries, and semantics

  • Several comments say merge conflicts are not the main pain; large monorepos, performance, and non-text assets (games, ML, design files) are.
  • Git LFS is seen as inadequate; alternative systems (e.g., dataset‑oriented tools, semantic/binary-aware layers) are mentioned.
  • There is strong interest in syntax/AST-aware or graph-based diffs and merges (tree-sitter-based tools, semantic diffs) as a more promising “future of VCS” than purely text/line-based CRDTs.

AI and the future

  • Some claim AI agents already make merge conflicts much less painful (LLMs resolving conflicts or full rebases).
  • Others report poor AI performance on complex rebases and see more value in preserving reasoning/intent alongside code than in swapping out Git.

Overall sentiment

  • Many welcome experimentation and the compact prototype, but view it as an interesting demo rather than a proven “future of version control.”
  • A substantial contingent believes version control’s foundations are basically sound; improvements should focus on UX, semantics, and scale rather than replacing Git’s core model.