Why Merge Base?

July 5, 2026

Software forges are, as a category, a late 1990s idea: "what if we put software on the web?". Look at me, calling the category "forges", that is, genericizing the name of SourceForge, and (reasonably) expecting you to understand what I'm referring to.

But in the 1990s, the most popular version control software was CVS. Which SourceForge would host for you, of course, and even Subversion when that came out. It was more centered around providing a basic project webpage with downloads for released source tarballs and builds, at least as a website, but this was valuable for developers.

We're not in the 1990s or 2000s anymore, and the most popular version control software is now Git. And there's a certain standard way forges look and behave now, which centers the source code repository instead of the downloadable build. Many of them started existing prior to the Software Freedom Conservancy getting strict about the "Git" trademark, and proudly bear a specific other piece of software's name in their name; we still hear from chagrined Mercurial users on occasion. (I simply don't know enough about it to support it. I apologize, Mercurial users. You deserve a Merge Base of your own.)

I like some of the changes that have happened since those days. Unifying the README file with the project homepage was a nice outgrowth of centering the source code repository; I wish it hadn't standardized on Markdown, but here I am typing this in Markdown; you may fairly reverse-Baudelaire me for that. Anonymous CVS existed as a difficult hack assembled by OpenBSD developers sticking to their principles, but anonymous Git is absolutely ubiquitous.

But there's a problem: we haven't escaped the long shadow of CVS. I don't enjoy using CVS as an insult, it's served faithfully for a long time. The problem is that CVS is a reliable workhorse of a centralized version control server, and Git is a shockingly good decentralized information management tool, and over 20 years after commit e83c5163316f89bfbde7d9ab23ca2e25604af290 (Initial revision of "git", the information manager from hell), we've chosen to pack it as well as we can into a CVS-shaped box, forgoing nearly all of what it's good at that CVS isn't.

So, why Merge Base? The thesis is that the tooling built around Git makes it more difficult to use Git as itself, a piece of software with its own useful features, rather than as an ersatz CVS substitute. Forges are the primary sort of tooling I mean here; day to day, users use the git CLI, IDE frontends that do similar things to it, and forges, and it's not the former two that are doing this. Which is what you'd expect; the characteristic feature of CVS is the central server (compared to its predecessor RCS, a command-line tool that works on local files), and that's exactly what forges are.

And those useful features are things many would benefit from being able to use easily. The Linux kernel was using a proprietary system at the time Git was first written; when it moved off that, it was absolutely never going to move to a CVS server (or Subversion, or anything like that), because that would simply not have worked. The requirement to acquire locks on committers (i.e., people with write access to the central server) would have ground even the 2005 development process to a halt, and made the history itself less meaningful.

There's a reactionary school of thought that opposes forges as they are today, but says we just need to return to patches on mailing lists, as Linus intended. There's not actually anything wrong with that model. Large, important projects like Linux or Git itself use it. But it presupposes the existence of a full-time maintainer, someone whose entire job is curating the repository, like Linus Torvalds for Linux (and famously, a hierarchy of vice-maintainers under him), or Junio Hamano for Git. It works very smoothly, there's hardly any such thing as a "conflict" and if there is the maintainer has reviewed both sides in detail already, and there's no such thing as Git chaos because everyone else is just using their local Git to email patches which the maintainer turns back into commits.

There's something admirable in this, but the whole workflow doesn't really address what people want out of a forge. Even if you couple it with some web features, the coincidence of "git expert" with "this-particular-project expert" in one person is rare. (It's obvious why Linus Torvalds and Junio Hamano are both.) In general, people are attempting to pursue some goal of their own by means of writing software which is version-controlled, not attempting to stake out a philosophical position regarding version control. (Of course, in writing Merge Base I am doing both. You are likely not, which is why it needs to exist.)

There are a lot of common instrumental goals people have in the process of writing software to pursue their terminal goals. They include goals like "I want to work in parallel with my coworker Alice, avoiding blocking each other, and smoothly integrate both our work when we're done." Or goals like "I want to release these 12 feature topics my development team of 8 people has finished in the past two weeks, which I think are deployable." Git's design is intended to make the former easy for contributors, and the latter easy for maintainers, but has it really done this for you? Or have you experienced baffling merge conflicts, release scrambles when things don't work together, and other such common experiences?

I contend that Git is designed right. (Maybe jj is a better CLI frontend. I have too much git muscle memory to use it myself, but everything I've read is good.) It just needs tooling support to fit into a complete workflow. That's why Merge Base.

Please feel free to email me.