When at work we migrated to monorepo, there was an implicit decision to drop commit history. I was the loudest one to make everyone understand how important it is.

> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions.

Well isn't it typical that the person who wrote is also the person that merged? I have never worked in a place where that is not the norm for application code.

Even if you are one of those insane teams that do not squash merge because keeping everyone's spelling fixes and "try CI again" commits is important for some reason, you will still not see who _wrote_ the code, you will only see who committed the code. And if the person that wrote the code is not also the person that merges the code, I see no reason to trust that the person making commits is also the person writing the code.

I really wanted to like this. The author presents a well-thought-out rationale for what conclusions to draw, but I'm skeptical. Commit counts aren't a great signal: yes, the person with the highest night be the person who built it or knows the most about it, but that could also be the person who is sloppy with commits (when they don't squash), or someone who makes a lot of mistakes and has to go back and fix them.

The grep for bugs is not particularly comprehensive: it will pick up some things that aren't bugs, and will miss a bunch of things too.

The "project accelerating or dying" seems odd to me. By definition, the bulk of commits/changes will be at the very beginning of history. And regardless, "stability" doesn't mean "dying".

Interesting ideas, but some to me seem very overgeneralizef, e.g.:

> How Often Is the Team Firefighting

> git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback

> Crisis patterns are easy to read. Either they’re there or they’re not.

I disagree with the last two quoted sentences, and also, they sound like an LLM.

Biggest life changer for me has been:

git clone --depth 1 --branch $SomeReleaseTag $SomeRepoURL

If you only want to build something, it only downloads what you need to build it. I've probably saved a few terabytes at this point!

Dying or stabilizing?

Most good projects end up solving a problem permanently and if there is no salary to protect with bogus new features it is then to be considered final?

Instead of focusing on the top 20 files, you can map the entire codebase with data taken from git log using ArcheoloGit [1].

[1]: https://github.com/marmelab/ArcheoloGit

To me all of these are symptoms of the problem that I outlined in my recent blog post: https://news.ycombinator.com/item?id=47606192

and it touches in detail what exactly commit standards should be, and even how to automate this on CI level.

And then I also have idea/vision how to connect commits to actual product/technical/infra specs, and how to make it all granular and maintainable, and also IDE support.

I would love to see any feedback on my efforts. If you decide to go through my entire 3 posts I wrote, thank you

Solid list. I'd add git log --all --oneline --graph pretty early on — gives you a quick sense of how active different branches are and whether this is a "one person commits everything" project or actually distributed. Helped me a ton on a job where I inheritied a monolith with like 4 years of history.

The git blame tip is underrated. People treat it like a gotcha tool but its maybe the fastest way to find the PR/ticket that explains a weird decision.

Saved. Very useful. Normally I just dig around the Github UI to see what I can glean from contributor graphs and issues but these git commands are a pretty elegant solution as well.