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.

▲

dgunay 7 minutes ago | parent | next [-]

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.

▲

kmacdough 2 hours ago | parent | prev | next [-]

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.

▲

Aperocky 4 hours ago | parent | prev | next [-]

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

▲

fenaer 5 hours ago | parent | prev | next [-]

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.

▲

joshstrange 5 hours ago | parent [-]

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.

	▲	troyvit 4 hours ago \| parent [-]
		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.

▲

4 hours ago | parent | prev [-]

[deleted]