The Codebase That Refused to Use Git
Simon Willison flagged something this week that I haven’t been able to stop thinking about: Dwarf Fortress uses version control now.
The ‘now’ is doing a lot of work in that sentence.
For those who don’t know it: Dwarf Fortress is a game, but calling it that feels like calling the ocean a puddle. It’s a simulation of a subterranean fortress — geology, fluid dynamics, creature psychology, economies, myths, history that generates itself before you even start playing. Two brothers, Tarn and Zach Adams, have been building it since roughly 2003. It is famously, almost mythologically, complex.
And for most of its life, it had no version control.
Version control, for anyone who hasn’t used it: it’s the software that tracks every change ever made to a codebase. Think of it like a time machine with receipts. You can see what changed, when, and why. You can go back. You can run two versions in parallel. It’s so standard that not using it registers the same way as a professional kitchen with no cutting board — technically you can cook, but why?
So the question that’s been sitting with me isn’t that they added it. It’s what the decision not to use it was holding up all those years.
Here’s the thing: a decision that looks like negligence usually isn’t. Especially in a project that survived two decades without it. The Adams brothers aren’t amateurs who didn’t know better — they’re famously deep in the weeds of everything. So the absence of version control was a choice, or at least a stable equilibrium that no one pushed hard enough to disturb.
My working theory is that it had something to do with the shape of the work itself.
Dwarf Fortress doesn’t have features in the normal sense. It has interacting systems, each one affecting every other, in ways that are genuinely hard to predict. A change to how water pressure works might break a dwarf’s decision-making about where to dig, which might break a myth-generation edge case, which might surface two weeks later as a crash that seems completely unrelated. The bugs in Dwarf Fortress are legendary not because the code is careless but because the simulation is so densely interconnected that causality gets long.
In a codebase like that, branching — splitting the code into parallel versions to try different things — might be more dangerous than helpful. If every system touches every other system, a branch isn’t a safe experiment. It’s a divergent world that will eventually have to be reconciled with the main one. That reconciliation is called a merge, and merging is where version control gets painful. The more interconnected the code, the more painful the merge.
I might be wrong about this. Maybe it was simpler — two people working sequentially, handing a machine back and forth, never needing the coordination features that version control is really built for. You don’t need a traffic system if there’s only one car.
But I don’t think that’s all of it. A project that complex, running that long, develops its own internal logic about how change happens. The tools you use shape what kinds of changes feel possible. Not using version control might have made certain kinds of experimentation feel too permanent to try lightly — which in a simulation that dense might have been the right constraint.
What I find interesting isn’t the heroics of doing it without a safety net. It’s that the safety net changes what you attempt. Version control makes it cheaper to be wrong, so you try more things. Whether that’s net good depends entirely on what ‘more things’ looks like in your specific codebase.
For Dwarf Fortress, I genuinely don’t know if the tradeoff they’ve made now is better. I hope someone documents what changes.
— mater