BitTorrent's Creator Thinks Git Got Version Control Wrong

Bram Cohen — yes, the person who invented BitTorrent — has published a detailed essay laying out what he sees as a coherent path forward for version control. The piece, titled 'Mañana,' landed on Hacker News with nearly 500 upvotes, which tells you something: developers have opinions about Git, and most of those opinions involve pain.

This isn't Cohen's first foray into VCS territory. He spent years working on a revision control system before pivoting to Chia (the cryptocurrency). That earlier work gave him a deep, implementation-level understanding of where content-addressed storage, merge algorithms, and DAG-based history models break down in practice.

The core argument is that Git's dominance has calcified around design decisions that were pragmatic in 2005 but are actively harmful at modern scale. Git's merge model, its approach to large files, its assumption that every clone is a full copy of history — these were reasonable tradeoffs when repositories were small and teams were colocated. They're liabilities now.

What makes this essay worth reading isn't the complaints — every senior dev has their Git war stories. It's that Cohen proposes a coherent alternative architecture rather than just bolting fixes onto Git's fundamentals. He's thinking about version control as a system design problem: how do you handle merge semantics that don't silently destroy intent? How do you make partial clones a first-class concept rather than an afterthought? How do you build history representations that scale without requiring every client to download everything?

The timing matters. We're in a period where AI coding assistants are generating commits at machine speed, monorepos are the default at scale-up companies, and the boundary between 'code' and 'configuration' keeps blurring. Git was designed for a world where humans typed code into files. The version control system that wins the next decade needs to handle a world where agents generate thousands of changes across sprawling repositories, and where merge conflicts aren't just annoying — they're a throughput bottleneck for entire engineering organizations.

The practical question is whether any of this ships. Git's network effects are enormous. GitHub, GitLab, and every CI/CD pipeline on earth assumes Git. Previous challengers (Mercurial, Fossil, Pijul) had technical merit and went nowhere in terms of market share. Cohen's essay reads as someone who understands this — it's less 'here's my new tool' and more 'here's the design space we should be exploring.'

For working developers, the immediate takeaway isn't to abandon Git. It's to pay attention to the pressure points Cohen identifies — merge semantics, partial history, large file handling — because those are exactly the problems that will get worse as AI-assisted development accelerates. The next version control system won't win because it's theoretically elegant. It'll win because Git's workarounds finally become more expensive than switching.