Git commands I run before reading any code

git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20

That’s the first of five commands in Ally Piechowski’s Git commands I run before reading any code, which was all over Hacker News on Wednesday. It lists the twenty files that changed most in the last year. The others rank contributors with git shortlog -sn --no-merges, find the files that show up most in commits mentioning “fix” or “bug”, count commits per month over the life of the repo, and grep the last year of history for reverts and hotfixes. Her point is that before you read a line of an unfamiliar codebase, the history can already tell you where the trouble is and who knows about it.

I’ve done versions of this for years, badly, by scrolling git log and getting bored. Having it as a list made me actually run it, so on Thursday I pointed it at one of our .NET services that I haven’t worked in for a long time and that’s due for an upgrade.

The churn list was right in an annoying way. The top file was the one I’d have guessed, the class that maps between the service’s database rows and its API responses, with 61 commits in a year. Second was a file I’d never heard of, a retry policy, at 44. The bug-fix grep had the retry policy at the top. So that’s where I’m starting, and it’s not where I’d have started.

The shortlog was the one I wanted to argue with. One person had nearly half the commits since last spring, and my first reaction was to worry about bus factor, which is what the article suggests. But I wrote a whole post in 2023 about how commit counts mislead, and they mislead in a new way now. That engineer does most of her work through an agent, and the agent commits in small steps, sometimes a dozen commits for a change someone else would push as two. Claude Code puts its own co-author line in the commit message, but shortlog counts the author, so all of those land on her. When I counted pull requests instead, she had about a quarter of them. Still the most, but not a bus-factor problem.

Piechowski already warns that squash merges distort the shortlog in the other direction, crediting whoever merged. Agents are the same warning with the sign flipped. Whatever you count, check how the team commits before you read anything into it.

The commits-per-month one was the most interesting to me as a manager, which is her point too. You can see the month we moved the service to a new database driver, and you can see the gap after the layoffs in 2022, and it’s a little uncomfortable to find both of those in a bar chart made of uniq -c.

I’ve put all five in a short skill file for Claude Code, so when I start a session in a repo I don’t know, the agent runs them first and tells me what it sees before it reads any code. That’s mostly worked. It’s better at summarizing the numbers than I am, and worse at knowing which ones to distrust, which is the part I still have to do.