4 ms·

I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dches

I think the reason for confusion is that you seem to say that people doesn't even commit their work when they work, but only when they're pushing as well. dchest is (seemingly) asking why don't you commit when you're done, but delay the pushing (according to your policies)?

dahart 7y ago
The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped. The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.
- martinhath 7y ago
  Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.
- atq2119 7y ago
  This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.
  - dahart 7y ago
    > that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. You're only talking about the first commit in a squash, and assuming that there aren't multiple squashes, right? There isn't only one timestamp in a squash, so you lose all but one of them. > I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Right, exactly, this illustrates why looking at timestamps isn't a good proxy for work time. > TFA doesn't discuss which timestamp is being looked at Here's the relevant portion of the script from the article: git log --author="Linus Torvalds" --date=iso

dahart 7y ago

The confusion was my fault, but I think is mostly gone now. I initially described it as commits when I was thinking of pushes, partly because I’m lumping both git and Perforce experience together. I edited my comments to be more clear, and it seems to have helped. The question asked is valid, and we do commit often, we only avoid pushes to shared spaces at night, so some commits may have representative time stamps. As others have mentioned, squashing might compromise that, and commits made Friday but pushed Monday are, in my experience, more likely to be modified Monday right before pushing. For me, it’s pretty rare that the first commit time survives until push, I’m almost always squashing code, multiple times, before it’s ever pushed.

martinhath 7y ago
Absolutely! In addition, if you've spent a full day on a single commit, it'll show in these stats as a single data point at the end of the day - the fact that you were working for the 8 hours leading up to the commit as well is lost.
atq2119 7y ago
This isn't entirely correct. Git commits have two timestamps: the author timestamp and the commit timestamp. Git only shows the author timestamp by default, and that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Unfortunately, TFA doesn't discuss which timestamp is being looked at, though that leads me to suspect that it's looking at the author timestamp because that's the default.
- dahart 7y ago
  > that timestamp definitely survives `git commit --amend` and other operations like rebase with squash. You're only talking about the first commit in a squash, and assuming that there aren't multiple squashes, right? There isn't only one timestamp in a squash, so you lose all but one of them. > I've had commits where the author timestamp was many months older than my last modification to the commit before finally pushing it upstream. Right, exactly, this illustrates why looking at timestamps isn't a good proxy for work time. > TFA doesn't discuss which timestamp is being looked at Here's the relevant portion of the script from the article: git log --author="Linus Torvalds" --date=iso