Reading History
You scroll git log and picture git reading a stored list of what happened, but nothing is stored. Each line was recomputed a breath ago by walking your commits, and recomputed again the next time you look.
- ▸Nothing under
.git/stores 'the diff of commit X'; git rebuilds it from two snapshots every time you ask. - ▸
git blamekeeps no author-per-line table; it walks history backward until each line's last change turns up. - ▸Re-run the same
git loga thousand times and.git/objects/gains zero bytes: reading never writes.
You run git diff to see what the last commit changed, skim the + and - lines, and move on. Where did that diff live before you asked for it?
The instinct is that git looked it up: opened some stored record of 'what changed here' and printed it. There is no such record. Nothing under .git/ is named 'the diff of that commit.' Nothing stores who wrote each line of app.py. Nothing keeps a list of which commits mention RETRIES. Each of those answers is computed the moment you ask, from data already on disk: the commit snapshots in .git/objects/.
It works because a commit is a full snapshot, not a record of edits. Each one points at a complete copy of the project, stored as blobs and trees, so given any two commits git can rebuild the difference between them by comparing what they hold. The answer is derived, never fetched.
The proof is cheap. Run the same git diff a hundred times and .git/objects/ does not grow by a single byte. Reading computes; it never writes.
From here the topic takes the four commands you read history with and exposes the computation inside each: walk the commits, compare two snapshots, trace one line back, search the bytes. Once you can see the walk, the output stops being magic and becomes arithmetic you could redo by hand.