Perfect Dark, 2025
Rare shipped Perfect Dark[1] for the Nintendo 64 in 2000. The source code stayed inside the company. When Microsoft acquired Rare in 2002, it stayed inside Microsoft. Nobody released it. Nobody was going to.
In September 2019, Ryan Dwyer made the first commit to a repository
called perfect-dark[2]. He did not have the source code. He had the
cartridge, a disassembler, and git.
Five years, six months, and 6,779 commits later, he was done. Not approximately done — exactly done. When compiled with the same compiler Rare used in 2000, the output matches the retail cartridge byte for byte.
The chapter ends with you cloning that repository and reading that history yourself.
The implementation pages open with the patch format that underlies every git commit, then build a complete workflow from the ground up: first commit, first branch, first merge conflict, first remote push. The final page is the payoff — you clone perfect-dark and read five years of work, commit by commit. Start at Setup.
Every Change, Forever
Before I understood version control I kept a folder called backup/.
Inside it: main_old.c, main_v2.c, main_working.c,
main_FINAL.c, main_FINAL2.c. None of them were the version I
actually wanted. Some were newer, some were better, some were just
different. After enough projects I stopped keeping backups entirely,
which meant I stopped being able to try things.
Git solves a different problem than I thought it did. I assumed it was about keeping old versions in case something broke. That is part of it. But the real gift is that it makes every change cheap. A branch costs nothing to create. A commit costs nothing to discard. The working tree, the index (staging area), and the commit history are three distinct zones with different levels of permanence, and understanding them changes how you work — not just which commands you run.
The conceptual anchor for git is older than git: diff and patch.
The diff -u command compares two files and produces a unified diff —
a structured description of exactly what changed, with context lines
above and below. patch applies that diff to the original file. C
communities have shared changes this way since before version control
existed. The suckless team — the people who maintain dwm, st, and
dmenu — still distribute all additional functionality as .patch
files. You fork their source, apply the patches you want, and build.
No git repository required on their end.
A git commit stores a snapshot of the entire tree alongside metadata:
the author, the timestamp, and a pointer to the parent commit. When
you run git log -p, git computes the diff between adjacent snapshots
to show what changed — the same unified format you produced with
diff -u. git format-patch turns any commit back into a .patch
file; git apply applies one. The format is identical.
I configured git, made some commits, read the log with
--oneline --graph, branched, diverged, merged back, and hit a
conflict. Resolving it by hand — reading the markers, understanding
which side introduced which change — made every merge tool feel like
an optional convenience rather than a requirement. Then I added a
remote on GitHub and pushed: the same commits, now readable by
anyone with the URL. Then I cloned perfect-dark.
Running git log --oneline on 6,779 commits made by one person over
five years, reconstructing something its original authors never
released, felt like reading a different kind of work journal.
The Project
- Install git and configure your identity:
git config --global user.nameandgit config --global user.email. - Generate an SSH key and add the public key to your GitHub account.
- Create a new directory, initialise it with
git init, and make your first commit. - Create a branch, make diverging commits on both branches, and merge them back together.
- Manufacture and resolve a merge conflict by hand — no merge tool.
- Add a remote on GitHub, push your branch, and pull the remote state.
- Clone
ryandwyer/perfect-darkfrom GitLab and explore its history:git log --oneline --graph --all.
Work through the exercises in order — the tester expects at least five commits on the main branch by the end.
The Tester
The tester lives in thecodingidiot-com/f02-version-control. It is a shell
script that verifies the shape of your repository, not the content of
your code:
- At least five commits exist on the main branch.
- A branch was created and merged back — the merge commit is present in the log.
- The conflict markers are absent from all tracked files (the conflict was resolved, not left open).
- A remote named
originis configured.
The perfect-dark clone step is self-certified. The tester cannot verify
what you saw when you ran git log on someone else's repository. That
step is the reward, not the test.