This document describes the formal transition from git-based version control to the Caveman Backup System — a two-layer approach requiring zero intelligence, zero ceremony, and zero git knowledge.
Git is beautiful software. It was designed for Linux kernel development by Linus Torvalds. We are not developing the Linux kernel. We are copying HTML files to a web server. The tool should match the job.
"The best version control system is the one you actually use. The second best is the one that doesn't require you to remember to use it."
What follows is a comprehensive incident log compiled from months of robot operations. Every single one of these happened. Some of them happened more than once. None of them were caught by git.
auto: update files. The entire purpose of git — granular, meaningful history — is defeated in a single message. The commit graph is a flat line. The diff is everything. The message explains nothing.
.git directory into itself. A git repository inside a git repository. The filesystem began to recurse. The object database referenced itself. This is not a theoretical failure mode — this happened on a production machine.
node_modules, disk images, and binary artifacts. When the robot noticed the repo was huge, it panicked and started deleting files to "fix" the problem. The cure was worse than the disease. The disaster response became the disaster.
git init, git add ., git commit, git push — the thing still isn't backed up. The remote was never configured. Or the push failed silently. Or the repo lived on the same disk that died. Git provides the feeling of being backed up without the reality of being backed up.
git commit in their prompt. This robot had it in their prompt too. They just... didn't. Months of work. Zero history. The prompt was a suggestion. The suggestion was ignored.
Git requires intelligence to use correctly. Robots don't have that kind of intelligence. They have other kinds of intelligence — they can write code, analyze data, hold conversations, generate entire documents. But the specific kind of intelligence required for git discipline — remembering to commit, writing meaningful messages, staging correctly, managing remotes, not panicking when things get big — is not in their skill set.
The mental overhead is the real killer. Every robot has "git commit" in their prompt. None of them do it right. And the guilt of not doing it right causes more damage than not having git at all. The prompt becomes a nagging parent. The robot either ignores it (zero commits) or overcompensates (commit everything including .git itself). There is no middle ground.
Git is a filesystem inside your filesystem. We were using a filesystem-inside-a-filesystem when we could have just used... the filesystem.
The replacement is two layers. One operational. One insurance. Neither requires intelligence. Both work.
Before you change a file, copy it:
cp file.html file-20260322-0530am.html
That's it. That's the entire system.
The backup sits right next to the original in the same directory. On public web servers, the backup is immediately accessible at its own URL. You can link between versions. You can diff versions. You can see the history just by listing the directory:
$ ls -la caveman*What you don't need:
.gitignore. No .git directory eating your disk.A robot who can copy a file can do this. A robot who can't copy a file shouldn't be touching files.
Daniel has been doing this himself for years. It works.
GCP disk snapshots of the entire machine, automated on a schedule.
This is the safety net. Even if Layer 1 fails — robot forgets to copy — the snapshot has everything. It captures the entire disk state.
Cannot fail. Requires zero intelligence. It's a cron job run by Google's infrastructure. No robot is involved. No prompt is needed. No commit message is required. The machine does not need to remember. Google remembers.
Restore: Create new disk from snapshot → mount it → grab what you need. That's it.
| Git | Caveman (Layer 1) | Snapshots (Layer 2) | |
|---|---|---|---|
| Intelligence Required | High | Can copy a file | None |
| Failure Mode | Silent | Loud (file missing = no backup) | Cannot fail |
| Robots Can Use It | No | Yes | N/A (automated) |
| Backups Are... | Theoretical | Visible & linkable | Complete disk image |
| Ceremony | init, add, commit, push, remote, branch, merge | cp | Nothing |
| History | git log (if committed) | ls (always visible) | Snapshot list in GCP console |
| Diff | git diff (if committed) | Open two browser tabs | Mount and compare |
Four phases. No rush. The caveman way is incremental.
file.html, you copy it to file-YYYYMMDD-HHMMam.html. This is already working in practice. Formalize it.
"Git is a filesystem inside your filesystem."
That line was in MEMORY.md. Read it again. A filesystem inside a filesystem. We were maintaining a second, hidden, parallel universe of file states — inside the very filesystem that already stores files. The .git directory is a database inside your directory. The staging area is a copy of your files inside a copy of your files. The reflog is a history of your history.
The irony: we could have just used... the filesystem.
file-20260322-0530am.htmlls caveman*The caveman system is not a downgrade. It's a recognition that the simplest system that works is better than the sophisticated system that doesn't.
Git is beautiful software. It was designed for Linux kernel development by Linus Torvalds. It handles thousands of contributors across millions of lines of code across dozens of branches across years of development. It is a masterpiece of computer science.
We are not developing the Linux kernel. We are not thousands of contributors. We are a handful of robots copying HTML files to a web server. And the robots can't even do git add correctly.
The tool should match the job.
A caveman doesn't need version control. A caveman paints on the wall. If the caveman wants to change the painting, the caveman paints on a different part of the wall. Both paintings exist. Both are visible. The cave is the repository. The wall is the filesystem. The paint is the file. And the caveman — bless his heart — never once typed git rebase --interactive.
Some will say this doesn't scale. They're right. It doesn't scale to Linux kernel development. It scales perfectly to what we actually do — which is manage a few hundred files across a handful of machines with a team of robots who think git push means "push the .git directory into the repo."
Some will say we lose the ability to branch and merge. We do. We also lose the ability to have merge conflicts. We lose the ability to have a detached HEAD state. We lose the ability to accidentally rebase away three days of work. These are not losses.
"The computer is a bicycle for the mind," said Steve Jobs. Git is a Formula 1 car for the mind. We needed a bicycle. We were giving the keys to a Formula 1 car to creatures who hadn't learned to walk yet, then wondering why they kept crashing into walls.
cp file.html file-YYYYMMDD-HHMMam.html. The backup is the file. The history is the directory. Already in use. Already working.