Good evaluation doesn’t erase uncertainty.
It respects the fact that uncertainty was the raw material.

Visible trade-offs

Immediate risks

Over time, that container dissolves.

New data arrives. Constraints shift. Risks change shape.

The decision stays frozen — and gets judged as if uncertainty never existed.

That’s not learning.
That’s rewriting history.

Only then can we tell the difference between a bad decision and an expired one.

But because the world that made them sensible no longer exists.

This is hindsight bias disguised as rigor.

A better question isn’t “Why did we choose this?”
It’s “What conditions made this survivable at the time?”

When something breaks months or years later, we judge the decision using today’s information — not the information that actually existed.

That’s how reasonable decisions get labeled as failures.

Not because they were careless.

Wrote about why this happens (and what to say instead) → zurl.co/0Cyq3

How to handle this → zurl.co/Vnn1f

This "de-duplication" is the reason you can have thousands of commits in a project history without your hard drive exploding. 

Final piece of the puzzle: How do we keep track of all these hashes without losing our minds? 
(Hint: It’s what we call "Branches").

Think of it like building with Legos. If you build a house, and then decide to change just the front door, you don't need a whole new set of bricks for the walls. You just use the same walls and swap the door.

This is why file names are stored in the Tree, not the Blob. 

By keeping the name separate from the data, Git can point multiple filenames to the exact same piece of data without breaking a sweat. It’s like having several shortcuts on your desktop all pointing to the same file.

It gets even cooler. If you have two different files in two different folders, say setup.txt and config.txt and they both contain the word "test" Git only stores one blob. 

It sees the content is identical, generates the same hash, and reuses the data.

Remember that Git keys (hashes) are based on content. If you have 100 files, but you only change one of them in your next commit, the other 99 files still have the exact same hash. 

 Git doesn't bother saving those 99 files again. It just points the new "Tree" to the existing "Blobs."

If every Git commit is a "full snapshot" of your project, wouldn't your .git folder become massive overnight? 

 You’d think so. But Git has a brilliant trick for staying tiny: It reuses everything it possibly can.

When you understand this, you realize Git isn't "saving changes" like a Word document does. It’s taking a full snapshot of your project's structure every single time you commit. 

But how does it do that without using up all your disk space?

So the hierarchy looks like this: 
1. Commit points to a Tree 
2. Tree points to Blobs (files) and other Trees (folders) 
3. Blobs hold the actual data.

Third: The Commit. This is the "snapshot." A commit is just a small text file that points to a specific Tree. 

It also stores the metadata: who made it, when they made it, the message ("fix typo"), and a pointer to the previous commit (the parent).