Everything in context. This is one of many reasons I'm a proponent of squash-and-merge. If a change really needs more than one permanent commit, it should probably be split up or if absolutely necessary should be on a feature branch maintaining similar process. Under this process, feature branches are not squashed.

This leaves developers to commit locally and comment as much or little as they like.

I suspect OP never actually ran these commands and this article was brainstormed and written by an LLM.

There's some giveaways that it was too. "It's not x, its y."

I'm getting a mixed reading, the most egregious flags aren't present, but there are a couple.

As you identified there is a lot of parallel sentence structure.

They also have a bunch of lists of 3-5 items which is a classic.

It doesn't have the anodyne rambling never getting to the point style common to LLMs

I'm starting to feel that this line of reasoning has turned into pseudoscientific divination. And it's really unfair to writers who put effort into blog posts.

Same. Someone we brought on that worked for about a month and vibe coded to hell caused a lot of damage in terms of tech debt and that list shows. Looks like he managed 124 commits in a single week. The same repo, our top dev only has around 500 in its entirety.

Also important to have a plan for code review and merges when a lead is out of town. I found out I needed to reevaluate how that's handed when I was gone for two weeks.

Not to diminish your lived experience, but this is sort of a management issue, no? There should be some expectations set and/or gates that need to be opened during PR about commit expectations. Some teams like a lot of commits to be a (messy) reflection of actual reality/history, others want the well-curated "story" with a bunch of squashes and rebases.

I think OP's context is: they get called to help troubled projects. Often the people that hired them might not know where exactly the trouble comes from.

If you look at a code base that's not really in trouble, these commands don't reveal the source of the trouble, because there might be none.

So that person, on one central codebase at a company I work for, is me.

Assuming I'm not ego-mad, I like to think this is because I built the project from the ground up before handing it over to the rest of the team.

These days other people commit more often than I do, but my name is still dominant, and probably will be for some time.

I'm not saying more commits = bad developer. In my example that happened to be the case but not because they had a lot of commits but because they were bad at their job. I was just trying to warn that taking these git snippets at face-value does not paint the full picture.

If someone came to me and said "I ran these and I see XXX was the most prolific committer and they left X months ago, what will be do???" I'd have to work hard not to laugh.

Since these snippets are self-described as ways to get familiar with the code/projects I wanted to provide the counter point. Most of those snippets do not at all paint the real picture and for all the repos I tested it on they paint the opposite of reality.

I know these codebases like the back of my hand, the purported purpose of these snippets is to better understand the codebase, I can tell you they don't work for anything I tested them on. Maybe they work for other codebases but the sample size I have access to says they don't work for me.

I haven't finished the article yet but I think your point is an important one, and that's to run the commands with a context in mind. The article seems to be coming from the perspective of somebody who is brand new to the project, and as your experience indicates, interviewing teams and leads before running those commands might add more understanding to what they're telling you.

Also - be careful of automated workflow that uses a single persons credential.. skews this by a lot.

Once word got out that a report was going up to a department head around commit frequency, a few of us started to make "backup commits" to boost our stats. Whether it be dev server config files (just in case!), local dev setups, whatever.. just something that changed enough on its own but would produce a steady stream of commits, while having some potential use case, however unlikely it was to actually be needed.

Modern problems require modern solutions and all...

Been there. At a company where KPIs became all the rage they asked each department to come up with KPIs to report on. The eng/dev department pushed back a bit saying there aren't any easy KPIs to surface and anything we did would either be trivial to game and/or would result in a bunch of extra work to track (like needing to add a ton of metadata to various tickets/processes to tie it all together). They didn't care and we settled on a bunch of BS metrics that we all knew were BS and trivial to game.

Yeah. I am the top committer at my current workplace, but I'd say that a majority of that gap is because my particular workflow results in many smaller commits than my coworkers.