Am I the only one who doesn't judge a programmers contributions by commits or change history?

Frequently I'm always near the bottom of contributors, because I don't make a million commits when it's broken. And I don't commit lines that will likely disappear in later commits. I like to finish a function, test it, check it, rework, and then make a "made function()" commit, as apposed to:

"Wrote function()"
"Wrote unit tests for function()"
"Fixed error"
"Code cleanup"
"Style guide compliance"
"Reworked function()"
etc.

Sorry that I keep my commit history clean and ensure it builds.

Yeah, thats annoying. But at least it's better than having them write no tests, have no style guide compliance, and no comments.

@gitreflog I agree. I'm glad they do all those things, but they don't see all the hundred of lines that I write, rework and eventually remove to make this beautiful, elegant 5 line function. And then have the audacity to say things like "keep up" or "well if you contributed more, I mean just look at the differences in the graph" like commiting broken, untested code filled with "//TODO:" some how makes them more useful and dedicated.

Same here. I squash my commits when I feel something should be in a single commit

When I was a young developer, I would ask the developers I looked up to, how many lines of code they wrote in a day... A few years later I would ask how many lines of code they eliminated.

Now I just ask to watch them work.

You can't use metrics to understand the real value of a developer.

This is a recurring theme where people are asking how to analyse developer performance.

I am yet to find a suggestion that accurately represents one's contribution to a project.

Dunno, if you're commiting on some short lived feature branch, it shouldn't really matter that much, since it will get merged anyways.

I think sometimes it's just not possible to to nail everything in the first go. I'd rather commit something roughly made, than delay it until it's finished.

When I was trying to push only completed stuff, I've noticed I ended up with too much local changes.

Again, I'm talking about short lived branches.

This is my current opinion, please correct me if I live in a lie.

Baby steps commits have a reason: track the developer activity and help the team to learn about the workflow style of each dev, IMHO.

It's obvious that some tasks don't require a profound level of commit details, but it's better than one single commit with multiple tasks/responsabilities.

Some years from now, other devs that don't even has the actual culture of your team anymore can understand so much by one commits that I can't standing by your side in that mindset.

Yes, most of the times I think like you, I hate messed histories and stuff, but in the end it's for the best. I expect to improve in that matter soon, because my team will only grow with that.