Reading git log as a career-long practice

The commit hash is a3f8c21. I pushed it on a Thursday afternoon in early 2022. The message reads: fix.

That’s the whole message. fix.

I’m looking at it now in a terminal, running git log --author="Arif" --since="2022-01-01" --until="2022-04-01" --oneline on a repo I haven’t touched in eight months. The history scrolls past. There are good commits in there — messages with real context, real reasoning. There’s also fix. There’s wip. There is one that reads ok now for real which I don’t remember writing and cannot fully explain.

The thing that stops me isn’t embarrassment. It’s the recognition that whoever pushed fix on that Thursday was working fast, under pressure, and had already decided that future-Arif could figure it out. Past-Arif was wrong. Future-Arif — which is me, now — has no idea what was fixed or why.

I stare at a3f8c21 for a moment. There’s something strange about being confronted by your own decisions stripped of all their original context.

Why engineers almost never do this

We are trained to look forward. The tools point forward. The standup asks what you’re working on today and what’s blocking you — not what you were thinking six months ago. The sprint board empties left to right. Every workflow in software development is designed to move you toward the next thing.

Reading your own history feels indulgent. Self-referential. The work is out there, shipping, not in here, reflecting.

I think that’s wrong. And I think most engineers quietly suspect it’s wrong, which is why the topic makes people slightly uncomfortable when it comes up.

Your git log is the only record of what you actually decided — not what you planned to decide, not what you told yourself you were doing, but what you actually committed to and pushed. The git log is a ledger. It doesn’t soften the entry. It doesn’t know you were tired.

Reading it means meeting yourself honestly.

Three things you learn from old commits

The pattern you didn’t know you had. Mine is the refactor-that-isn’t. I keep writing commit messages like clean up auth module or simplify token handling that, when I read them three months later, are actually substantial logic changes buried in cosmetic phrasing. The pattern shows up again and again. I was clearly uncertain about the change and used cleanup language to hedge it. Now that I see the pattern, I can name it when I’m doing it. That is more useful than any retrospective.

The judgment that held up. In the same early-2022 log, there’s a commit three weeks before a3f8c21 that reads: use read replicas for reporting queries — main db at 80% capacity, this buys time before schema work. That commit was boring. It wasn’t clever. It was the obvious move made carefully, with context written down. It bought six months, not the two weeks I’d estimated. The boring, well-described decisions are the ones that compound. I’ve found this consistently across different repos, different years. The flashy ones rarely look as good three months out.

The judgment that didn’t. There is a commit in a different repo that reads replace ORM queries with raw SQL for perf — 40% faster in load test. I remember being quite proud of that one. Reader, it was a maintenance disaster. The load test was unrealistic. The raw SQL spread across eight files over the following sprints. Eighteen months later someone rewrote the whole layer. The commit message had the confidence of someone who had run one benchmark and called it decided. I can see that now. I couldn’t then.

The commit message as a letter

Tim Pope’s note on commit messages is fifteen years old and still the clearest thing written on the subject. The imperative mood, the 72-character wrap, the blank line before the body. The mechanics matter, but the underlying principle matters more: write the message for the person who will read it next, knowing nothing about the context you’re standing in right now.

That person is often you.

Linus Torvalds put it more bluntly: a commit message should describe what changed and why, not just rephrase the diff. The “what” is visible in the diff. The commit message is for the “why” — the thing that disappears completely when the context does.

fix tells me nothing. fix session expiry on mobile safari — token was being cleared on blur event, not on actual logout tells me everything I’ll need in eighteen months. It takes ninety seconds longer to write. The asymmetry is absurd.

Write them like you mean it. Write them like you’ll be grateful.

The practice itself

Once a quarter, I spend twenty minutes reading three months of my own git log. Not to audit myself. Not to feel good or bad about what’s there. Just to see what’s actually in the record.

The command I use:

git log --author="Arif" --since="3 months ago" --pretty=format:"%h %ad %s" --date=short

I read the messages in bulk. I’m looking for patterns — both in the work (what kinds of problems kept coming up) and in the writing (what I was clearly trying to avoid saying, what I documented well without realizing it). I note what I got better at versus what I thought I was getting better at. These are often different things.

The practice is not therapy. It’s calibration. You cannot improve at something you won’t honestly observe. The git log is the observation.

If the messages are thin — a lot of fix, a lot of update, a lot of wip — that’s information too. Thin messages usually mean the work itself was unclear. That’s worth knowing.

Back to a3f8c21

I run git show a3f8c21. The diff is twelve lines. A null check on a response object, a defensive early return. It was clearly fixing a crash. It took someone maybe twenty minutes to write, probably less.

There’s no message because past-Arif decided the fix was obvious and future-Arif would understand. Past-Arif was making a small bet: that this would never matter.

It almost never does. That’s the trap.

Because the one time it does — when there’s a regression, when someone’s debugging a related issue at 11 PM, when you’re trying to understand whether this was a deliberate choice or an oversight — the message is what they have. And fix is what you gave them.

a3f8c21 is a small thing. Twelve lines, four years ago, mostly forgotten.

I still remember it now.