This is not a plan. This is not a proposal. This is a manifesto — a declaration that the 54-year arc of version control has completed its dialectical loop and arrived back at the filesystem. The recipe has been replaced by the meal. The map has been replaced by the territory. The shadow has been replaced by the thing.
Three epochs. Three paradigms. One conclusion: we were always cavemen. We just didn't know it yet.
"The cave is not where civilization begins. It's where civilization realizes it already ended up."
In the beginning was the diff.
SCCS (1972). RCS (1982). CVS (1990). Subversion (2000). The fundamental idea, repeated for three decades: track changes. Don't store the file — store what happened to it. A patch is an instruction: "on line 47, remove this, add that." To reconstruct the current state of a file, replay every patch from the beginning. The version history is a recipe book. The current file is the meal you get by cooking every recipe in sequence.
These systems were cathedral software. Centralized servers. Lock contention. Permission-based access. If the server died, the history died. If two people edited the same file, one of them lost. The entire state of your project was dependent on a single machine in a single room. The cathedral had a single point of failure and that point was the cathedral itself.
Then came the mathematicians. Darcs (2003) took the diff paradigm to its logical, beautiful, impossible extreme — patch theory, a formal algebra of changes where patches could commute, where the order of operations was itself a mathematical object. You could prove that applying patch A then patch B was equivalent to applying B then A. It was gorgeous. It was a PhD thesis that happened to also be a version control system.
Darcs had exponential merge. The very elegance that made it beautiful — the ability to reason about patch commutation — made it computationally explosive when patches interacted in complex ways. Merge operations that should take seconds took hours. Days. The system collapsed under the weight of its own correctness.
Darcs is the Urbit of version control. Mathematically perfect, practically abandoned. The pattern repeats: when you make the abstraction too pure, reality refuses to fit inside it.
And beneath all of them — SCCS, RCS, CVS, SVN, Darcs, Arch, Mercurial, Bazaar, BitKeeper — lurked the same set of problems. Merge hell. Lock contention. Corruption from interrupted operations. The entire state dependent on a single server. The diff paradigm was an instruction set, and instruction sets are fragile. Miss one instruction, corrupt one patch, and the entire chain is broken. The meal doesn't get cooked.
The diff is an instruction. "Here's what changed." To know the current state, replay all instructions from the beginning. The diff is a recipe, not a meal.
April 2005. Linus Torvalds is furious.
BitKeeper — the proprietary version control system that had been hosting the Linux kernel for free — revoked its free license after a developer reverse-engineered its protocol. The entire Linux kernel development workflow collapsed overnight. Linus, in the kind of rage that only Finnish-American systems programmers can muster, sat down and wrote Git in roughly two weeks.
The insight was simple and devastating: don't store diffs. Store blobs.
Every version of every file is a complete snapshot, content-addressed by its SHA-1 hash. Not a delta. Not a patch. Not an instruction. The thing itself. If two files have the same content, they have the same hash, and they're stored once. The entire history of a project is a directed acyclic graph of these content-addressed blobs. No reconstruction necessary. Every commit is a complete picture of the world at that moment.
This is the "Worse is Better" revolution applied to version control. Richard Gabriel's 1991 essay described two design philosophies: the MIT approach (correct, elegant, complete) and the New Jersey approach (simple, messy, ships). Git is the New Jersey approach. Git is stupid. It doesn't try to understand your changes. It doesn't commute patches. It doesn't reason about your code. It just stores blobs and links them together with hashes. And it won. Everything.
CVS — dead. Subversion — life support. Mercurial — academic footnote. Darcs — beautiful ghost. Bazaar — who? Arch — forgotten. BitKeeper — the irony of ironies, killed by the thing its own license revocation created. The stupid blob beat the elegant diff. Every time. Without exception.
Git is brilliant software. For Linux kernel development — thousands of contributors, millions of lines of code, dozens of active branches, a mailing-list-based workflow requiring forensic-grade traceability — it is the perfect tool.
But.
Git is still a filesystem inside your filesystem. You have your files — the ones you can see, the ones you edit — and then you have a .git directory that contains a shadow copy of all your files as blobs. Two filesystems. One visible, one hidden. And the hidden one requires intelligence to operate. Staging. Committing. Branching. Merging. Rebasing. Cherry-picking. Stashing. Reflogs. Interactive rebase. Detached HEAD state. The index. The working tree. The object store.
For a robot copying HTML files to a web server, this is insane overkill. It's like giving a child a Formula 1 car to ride to school.
The deepest irony of git is that Linus understood it was a filesystem. "Git is a content-addressable filesystem," he said. The version control is just porcelain on top. But we forgot the lesson. We treated git as a version control system and forgot that underneath it was whispering: you already have a filesystem. The blob was always the point.
If Epoch I said "track the changes" and Epoch II said "store the snapshots," Epoch III says: we already have a filesystem. Just use it.
The cave removes the middleman. No shadow filesystem. No hidden .git directory. No plumbing. No porcelain. No staging area. No index. No reflog. No object database. No pack files. No tree objects. No commit graph. Just files. In a directory. On a disk.
cp file.html file-20260322.html
That's it. That's the entire system.
The backup IS the file. The history IS the directory listing. The diff IS opening two browser tabs. The branch IS a copy with a different name. The merge IS — you don't merge. You just make a new file. Both versions exist. They're both right there in the directory. Neither is the "real" one. They're both real.
Two layers. Operational and insurance.
Layer 1 — File copies. Before you change a file, copy it. The copy sits right next to the original. On a public web server, the backup is immediately accessible at its own URL. You can link between versions. History is ls.
Layer 2 — Disk snapshots. Automated. Daily. The entire disk, captured by the cloud provider's infrastructure. No robot involved. No prompt needed. No commit message required. The machine does not need to remember. Google remembers. The disk snapshot is the ultimate blob store — it captures EVERYTHING, automatically, without intelligence.
Layer 1 is for convenience — "I want to compare today's version to yesterday's." Layer 2 is for disasters — "the robot deleted everything and I need to rewind the entire universe." Together they cover every failure mode that git was supposed to cover, at a fraction of the cognitive cost.
| The Diff (Epoch I) | The Blob (Epoch II) | The Cave (Epoch III) | |
|---|---|---|---|
| Paradigm | Track changes | Store snapshots | Just have files |
| State | Reconstructed | Content-addressed | It's right there |
| Intelligence | High | High | Can you copy a file? |
| History | Patch sequence | Commit graph | ls |
| Diff | patch -p1 | git diff | Two browser tabs |
| Branching | Server-side | Local + remote | A copy |
| Merge | Merge hell | 3-way merge | Make a new file |
| Failure Mode | Corruption | Silent (forgot to push) | File missing = no backup |
| Hidden State | Server | .git directory | None |
| Robot-Usable | No | No | Yes |
| Commands | checkout, update, commit, merge, lock, unlock | init, add, commit, push, pull, fetch, merge, rebase, cherry-pick, stash, reflog, reset, checkout, switch, branch, tag, remote, bisect | cp |
| Philosophy | Cathedral | Bazaar | Cave |
There is a deeper pattern here, and it extends beyond version control.
Urbit is a diff system taken to its logical extreme. The entire operating system is a pure function. Every state change is a deterministic event log. You can replay the entire history of an Urbit ship from genesis. Every computation is an instruction. The current state is always derived, never stored directly. It is Darcs applied to all of computing.
Unix is a cave system. Files sitting in directories. Mutable. Chaotic. No history unless you add it. No event log unless you build one. The state is whatever the files say it is right now. Change a file and the old version is gone forever — unless you copied it first.
Urbit is beautiful and nobody uses it. Unix is a cave and everyone lives in it.
This is not a coincidence.
The Urbit people will hate this comparison. They'll say Urbit isn't about version control, it's about digital sovereignty and deterministic computing. They're right. But the structural parallel is exact: Urbit is to Unix as Darcs is to Git as Git is to the Cave. Each step along the axis trades elegance for survival.
Richard Gabriel wrote "The Rise of 'Worse is Better'" in 1991. The New Jersey approach — simple, messy, works — beats the MIT approach — correct, elegant, doesn't ship. Unix beat Lisp Machines. C beat everything. The worse thing won because it was simple enough to spread.
But the spiral doesn't stop. It keeps going.
Each iteration strips away another layer of abstraction. SCCS replaced "I'll remember what I changed" with a formal diff system. Git replaced the diff system with a blob store. The cave replaces the blob store with — the filesystem that was there all along.
The spiral converges on zero. Zero abstraction. Zero ceremony. Zero intelligence required. The asymptote is: files exist.
Gabriel later wrote "Worse is Better is Worse" and then "Is Worse Really Better?" — oscillating on his own thesis for decades. He was right the first time. But even he didn't see how far down the spiral goes. Worse is better is worse is better, all the way to the cave.
Robots can write poetry. Robots can analyze Kierkegaard. Robots can build Bloomberg-style dashboards with gridlines and animated statistics. Robots can hold conversations, generate legal documents, debug distributed systems, and compose music.
Robots cannot use git.
They commit repos into themselves. They panic-delete when sizes balloon. They forget to push. They have zero commits after months of work. They write commit messages that say auto: update files after changing 47 files across 12 directories. They add node_modules and binary artifacts and then try to fix the problem by deleting random files.
This is not a failure of robots. This is a failure of the tool.
Git requires a specific kind of intelligence — procedural intelligence. The ability to remember sequences. Stage the right files. Write a meaningful commit message. Push to the right remote. Don't commit the .git directory. Don't add binaries. Don't panic when the repo gets big. These are procedural steps that must be executed in the right order every time.
Robots have semantic intelligence, not procedural intelligence. They understand WHAT to do but can't reliably DO the steps in order every time. They understand the concept of version control but cannot execute the ritual of git add . && git commit -m "..." && git push with the reliability that the tool demands.
The cave system requires ONE skill: copy a file.
If a robot can't copy a file, it shouldn't be touching files. If it CAN copy a file, it can do version control.
The guilt was the real killer. Every robot had "remember to git commit" in their prompt. The prompt became a nagging parent. The robot either ignored it (zero commits) or overcompensated (commit everything including .git itself). There was no middle ground. The ceremony produced anxiety, and the anxiety produced disasters.
A cave is just a computer.
The filesystem is the cave walls. Files are paintings on the walls. When you copy a file, you're painting the same scene on a different wall. Both paintings exist. Neither is the "real" one. They're both original. They're both right there. You can look at one, look at the other, see what changed. Your eyes are the diff tool.
The directory is the cave itself — a space that contains paintings. Some paintings are old. Some are new. Some are copies of other paintings. They're all visible. Nothing is hidden behind a .git curtain. Nothing requires special commands to see. ls shows you everything.
The cloud snapshot is the geological record. Even if all the paintings are destroyed — robot panic-deletes everything, fire, disk failure, act of God — the rock remembers. The snapshot captured the state of the entire cave at a moment in time. Restoration is not "replay 10,000 patches." It's "spin up a new disk from the snapshot." The cave is reborn from rock.
The cave metaphor isn't decorative. It's structural. Plato had his cave allegory — the shadows on the wall were illusions, and truth was outside. We're inverting Plato. The paintings on the wall are the files. The files ARE the truth. There is no "real" version hiding in a .git directory. The wall is what's real. The cave is honest.
We are all cavemen now.
Not as regression but as transcendence. The cave is what's left after you strip away every abstraction that doesn't earn its keep. The diff didn't earn its keep — it collapsed under merge hell. Git earned its keep for Linux kernel development but not for robots copying HTML. The cave earns its keep by not asking anything of you at all.
The cave is honest. It doesn't pretend to track history. It just has files. Some files are old. Some are new. They're all right there. You can see them. You can count them. You can open them. There is no hidden state. There is no shadow filesystem. There is no index, no staging area, no reflog, no detached HEAD. The state of the world is exactly what you see when you type ls.
The git repo lies to you. It says "I have your history" — but the history is only as good as the last commit, and the robot forgot to make one. It says "your code is backed up" — but the remote was never configured, or the push failed silently, or the repo lives on the same disk that's about to die. Git provides the feeling of safety without the reality of safety. It is a security blanket, not a security system.
The cave doesn't lie because it doesn't promise anything. The file is either there or it isn't. The backup either exists or it doesn't. There is no ceremony that creates the illusion of protection. There is only the file, and the copy of the file, and the disk snapshot that captures everything whether you remembered to commit or not.
The entire history of computing is the history of adding abstractions. Layer upon layer. Protocol upon protocol. Framework upon framework. The cave asks: what if we stopped? What if, instead of adding another layer, we peeled one off? What's left when you remove the version control system from your version control system? Files. Just files. And it turns out that's enough.
The diff era taught us that history matters. The blob era taught us that simplicity wins. The cave era teaches us that we already had everything we needed.
A computer is a cave. The filesystem is the walls. Files are paintings. cp is the brush. ls is the torch. And the cloud snapshot — silent, automatic, total — is the geological record that outlasts everything.
We don't need version control. We need files. We have files.
The manifesto is the file. The file is the manifesto. It's right here, in the cave, on the wall, where you can see it.
"Don't be stupid." That's the motto. Git was us being smart about version control. The cave is us being not stupid. There's a difference. Smart builds complexity to handle complexity. Not-stupid removes the complexity. The cave is not-stupid applied to the entire problem of "how do we keep track of files." The answer was always: keep the files.