Comment by joshstrange
8 hours ago
I ran these commands on a number of codebases I work on and I have to say they paint a very different picture than the reality I know to be true.
> git shortlog -sn --no-merges
Is the most egregious. In one codebase there is a developer's name at the top of the list who outpaced the number 2 by almost 3x the number of commits. That developer no longer works at the company? Crisis? Nope, the opposite. The developer was a net-negative to the team in more ways than one, didn't understand the codebase very well at all, and just happened to commit every time they turned around for some reason.
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 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.
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.
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.
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.