You're attempting to defend the relevance of your comments to an article about the development practices of, among other people, Linus Torvalds, by saying, "Most devs in my experience are not git experts, and they don’t always use git in best practices kinds of ways." Perhaps you are not aware that Linus Torvalds originally wrote Git, and did so specifically to mechanize what he considers to be "best practices".

Edited to add: apparently something in my phrasing is leading you to believe that I'm angry with you and wanting to attack you. I'm not sure what that is, but that isn't my intention. I just think what you're saying isn't true, or rather is presumably true of your company but not of this article, and I was trying to explain why. I'm sorry for writing in what is apparently an aggressive tone.

Thank you, yes I’m well aware that Linus wrote git. I’m not sure what made you so angry, but I’m up for continuing this discussion if you’re really open to discussion, as opposed to proving me wrong no matter what. It currently feels like the latter, but I think you’re not listening or understanding what I’ve said. It seems like you’re making assumptions.

Maybe you missed that I pointed out above that Linus makes a lot of merge commits, and you’ve just ignored my previous point about merge commits which is completely and directly relevant to my comments. The article included Linus’ merge commits in their histogram of his commit times. If Linus is waiting to merge like I do, then the data is skewed. If Linus is code reviewing and emailing in the morning, and writing code at night, then the data is misleading.

The merge commits made by Linus will have as their date and time the time when he made the merge locally on his own machine, which can be different from the time that he pushed those changes out (and given that he specifically designed git to have this capability it seems rather plausible that he uses it).

Merge commits are really the same as non-merge commits. The only difference is the number of parent commits, which is irrelevant for this discussion.

For what is worth kragan is entirely right here.

As strawman arguments often are within their own context. That doesn't mean I'm wrong. My point that merge commits were included in the OP's article and data went unanswered by @kragen, and it's directly relevant to what I said at the top; merge commits don't represent work time, but they're being counted here. Code commits also don't necessarily represent work time either, due to squashing, stashing, and general dev practice, so I haven't heard any evidence that convinces me otherwise. Do you have any to add?

Merging is work too. The times of merges are indicators that the person did work at that time.

Obviously the methodology is limited but it does seem to work well in practice. If you have evidence that the statistics are wrong for one of the listed programmers, please do share it.

Your attack on my integrity here is unwelcome and entirely unwarranted; that does make me angry. I regret having given you so much of my time in this thread and having assumed good faith on your part.

> Your attack on my integrity here is unwelcome

I absolutely did no such thing. You may wish to consider taking that untrue statement back, for the sake of your integrity. Nothing I said is attacking you personally in any way.

You called for a retraction of my top comment, implying it is flip-flopping and hypocritical, but you misunderstood my argument and made a rebuttal point that didn't address mine. That's a straw man, and since you appear to believe "straw man" is judgemental, it is not. It simply means you're arguing against a different point than the one I made.

It's a fact that you haven't yet responded to the merge commit point I made, and that merge commits in the OPs data are relevant to my original comment.

> I regret having given you so much time

You make it sound like I'm supposed to appreciate you calling my words untrue and "completely irrelevant". How does arguing with me and saying I'm attempting to defend an irrelevant position amount to you extending good faith?

I find kragan's comments to be creating strawman arguments. They are unnecessarily confrontational.

> You can’t count on commit times to demonstrate anything.

Very extreme stance! Especially for so deep in thread. Sometimes it’s nice to make your ideas more specific as you go deeper in conversation, not just radicalize and double down.

Interesting; I don’t consider what I said extreme or radical at all. I’ll rephrase it into a question: what do you claim that commit time demonstrates, considering that commit times can and do in practice very often change immediately prior to push?

Commit time has some correlation with when code is written. It’s not perfect, but for me personally it’s usually close.

Whether that correlation models reality closely enough to be useful depends.

My understanding of your “commit time demonstrates nothing” assertion is that you are saying there is no useful information there, which seemed like a radical position for so deep in the thread.

How can a commit time change?

git commit --amend changes author time.

git commit --amend --reset-author changes both author time and commit time.

git rebase changes commit time.

All three commands can be used just before a merge and push to clean things up. So there is no guarantee that the author time or commit time we see in the final commit history accurately represents the actual time at which the work was done.

It's a different commit. I was talking about introducing and then pushing new commits with different timestamps than the original, not somehow modifying timestamps on a specific commit. The commit that gets pushed can, and often does, have a different timestamp than the timestamp on the commit when the code was written.