Version control second coming

The very same week we signed our first ever angel investor for Plastic SCM, in early summer of 2005, Linus Torvalds announced Git. I had spent more than a year pitching investors to build a new version control, and suddenly the creator of Linux was building one himself. That week I understood the road ahead was going to be much harder than I had anticipated.I hadn’t felt that same electricity again in twenty years. Until a few months ago.While we all stopped coding manually around December 2025, something else was cooking: the biggest revolution in version control since 2005.Two big pushes happening simultaneously: the need to handle a much higher commit pace due to agents, and a sudden urge to replace GitHub.I’m going to reflect about these two forces plus what we can probably expect in the near future from version control as it both adapts and supports new ways of developing software.Fair warning: I’m anything but neutral. I spent twenty years competing against Git with Plastic SCM, I spent about two years advising Activision on their gigantic monorepo, I advise Diversion, and I now work at Origin making Git faster than anyone thought possible — so I’ve seen this fight from every corner of the ring.The fall of the giantsIf only 2 years ago somebody said GitHub would be no longer relevant soon, nobody would believe them. GitHub was the undisputed leader in repository hosting, and it also shaped the way developers thought about version control. Having spent too much time as a competitor (more about that later) I suffered that: if something was different than what people understood it was ‘the way GitHub does things’ it was probably wrong.GitHub is still gigantic in both repos and minds, and its impact in the world of software development and collaboration in general has been enormous, and most likely it will continue to be.But if you have been around long enough, you probably remember there was a time when nobody would bet against SourceForge, and only a couple of years later, with the rise of GitHub, it became largely irrelevant.Are we living now in the same transition moment? GitHub has done too many great things over the years, so I hope it remains, but there is obviously an earthquake going on.My life in version controlIf you’re reading this chances are you know I co-founded Plastic SCM, the version control that is not Git, back in 2005. It was all about performance and gigantic repos, and it was acquired by Unity in 2020.The first version control I used, though, was Visual Source Safe, in my first official job after university, back in 2000. Known as VSS it has been one of the most blamed version controls ever, but perspective taught me that it had some pretty good things too: extremely simple, and very easy to share files among projects, something probably yet not resolved.A few months later I had the chance to put my hands on Clearcase, by then acquired by IBM, when I joined Sony in Belgium to develop digital televisions. I was shocked at first, but Clearcase blew my mind. It had incredibly good branching and merging, virtual filesystems, and it was extremely flexible. I used it mostly from a Sun workstation, and I was lucky not to touch its “simplified” version back then (which in my opinion helped to kill it, since it shaved most of its power).Clearcase was extremely expensive, my memory tells me something around 5k/year per user for an enterprise setup.The version control bug bit me hard. Wouldn’t it be amazing to have something as powerful as Clearcase but more affordable so small companies could use it too? Then I learned Subversion and CVS, and even Perforce (which is still THE solution for many large game dev teams and chip makers).We started Plastic SCM in summer of 2005 after more than one year trying to create a business plan pitching potential investors.After that, I saw a good number of version controls come and go: Accurev was a fantastic solution we competed against many times, and it is now largely gone. Team Foundation Server from Microsoft, Jazz from IBM (trying to replace Clearcase), Serena, and many others that are hard to hear from anymore.2005 was the last big explosionCirca 2005 there was a race to win the versioning of the Linux Kernel. Bitkeeper had to be replaced (it is a story on its own) and Mercurial, Darcs, and a few others wanted to win that crown. To be honest, my dream when I was trying to get Plastic SCM started was also to version the Linux kernel. In my head it looked fantastic, little I knew a commercial product would never be even remotely considered for that. But only if you are naïve enough you would start a new version control, I guess.Then Git entered the race — the same announcement that shook me that summer — and won it. It was a revolution, and a little bit later, around 2008, GitHub brought it to the masses and the rest is history.It was incredible to see the new systems coming around that time, Git and Mercurial being probably the two most heavily adopted.The second explosionBy the end of 2025 I had the luck to talk with some different teams developing new version control solutions. With some of them I already had contact for a long time, and others were new to me, but the thing I started to perceive is that obviously something was going on.Nobody dared to challenge GitHub supremacy, but now startups here and there were trying to create “the next GitHub”.I’m sure I’ll forget some very relevant initiative, but here go the key ones I was more excited about.EntireEverybody was shocked when Thomas Dohmke, the former CEO of GitHub, announced a gigantic seed round for his new venture, a new version control system solution based on Git.They have released provenance tracking to basically know what code which agent created and which prompt, which I believe is going to be a must in how we handle version control, and also a number of performance improvements (like super fast clones thanks to distributed replicas worldwide).PierreVisiting their website is an experience by itself (not sure how long this will last) because it is quite different to anything else. Pierre has released better diffs and better trees, open source, so anybody can empower their code UIs with them, but then focused on code.storage, their Git forge for the agentic reality.GitHub hit a wall in terms of performance when dealing with an incredibly high increase of commits, PRs, and traffic in general, and code.storage positioned itself as the solution for all platforms using repositories underneath, at AI scale.In recent posts in X they unveiled how Lovable and other massive AI solutions rely on their system to handle repositories.It is, definitely, one of the most promising Git based solutions out there.OriginIt was the last I heard about, but when I did I really realized something big was happening in the industry. Cursor (now SpaceXAI) working on their own Git forge too? Amazing.Origin is also a full Git forge, with a full solution for pull requests, repo hosting, etc, and has focused on performance and reliability so far, but like all the other Git platforms, this is just the start of a quite exciting trip.My friend and colleague Vmg posted an incredible writing about origin internals (https://cursor.com/blog/git-at-any-scale) that spiked an ‘WAL S3’ discussion on X for a few weeks. People like Scott Chacon and Tobias Lütke implemented their own versions in the next few days, inspired by Vmg’s post.This is the team I joined a few months ago, as I said, to work full time again on version control internals — so judge my enthusiasm accordingly. This time, instead of racing against Git, I’m trying to make it as fast as I can.GitButlerScott Chacon’s new version control venture has been around for a few years already, but they are now positioned as “version control for your agents”, which elaborates more in the same trend, although with a different approach.So far GitButler is not a new forge but focused more on the client side, with radically different user experience concepts, a focus on performance.Stacked branches (we all need them in my opinion), better rebasing and as I mentioned, innovative ideas they explored like ‘virtual branches’ makes them part of the cutting edge in Git evolution.East River Source Control - https://ersc.ioThe first ones in my list that are not creating something around Git… but around Jujutsu.I had the chance to talk a few times with the version control team at Google (and I always enjoy every minute of the conversation, they are so next level, specially in something I love which is super gigantic monorepos) and they put me in touch with this team, who is bringing Jujutsu to the market.Jujutsu was started at Google by Martin von Zweigbergk (who I also have the privilege to be in touch with) as a successor to Git. It brings innovative ideas like stacked branches, and goes beyond that versioning even unsolved conflicts in the repo, which opens up new previously impossible opportunities.Rearranging commits, reapplying changes (pure stacking) becomes a totally different experience.Jujutsu can work on top of Git, but internally at Google they use a different backend, and ersc tries to bring that idea to the market. You lose part of Jujutsu’s extra power when you push to GitHub, and a native backend would change that.I expect a lot of evolution coming from the Jujutsu land, not sure if native or transplanted to Git or other version controls.DiversionI’ve been collaborating with Diversion for over three years now as an advisor. They have been around for a few years now and they are also not based on Git. At first they reminded me a lot of my old days at Plastic SCM, fighting Gits here and there with a totally different stack.Their approach is quite different, though, and I think this is what makes them so relevant in this ‘version control revolution’: they have been born in a post-decentralized world. I was in love with the fact of pushing/pulling to remote repos, and in fact in