I guess answers will be related to your view on what a git log should represent in your project: is it an accurate account of the work that was done, or a story of how the code was written? The difference is subtle but important for this discussion.
In my practice, I prefer pull request commit logs to show an accurate account of the work that was done for the sake of providing development context to reviewers. But I prefer the commit log of the project as a whole to tell a higher-level, cohesive story of how the project changed over time; as such, I am often squashing, rewriting, and reorganizing my feature branches prior to merging them into the project trunk.
Given this sort of workflow, which constantly changes commit SHAs and timestamps, I never look at commit timestamps except to determine when a bit of code was introduced to the code base, and rarely does anything more granular than "day of month of year" matter to me.
So I tend to view commit timestamps as capturing the birth of code as witnessed by the codebase rather than as an accurate representation of when it was written. From this perspective, I don't think the addition of "real-time work tracking" to the project history is useful to me most of the time.
Now, all of that said, I love the idea from a personal productivity and effectiveness angle 😍 I've thought many thoughts about ways to encode more of the human factor into commits for later analysis. It's really fascinating and also poses terrific challenges!
There's a difference between real-time work tracking for a project, and for a person. And there's a problem with how to define "work" in both cases: how do you capture/represent the effort that went into every commit? This includes rewriting, testing, debugging, begging the tiny gods of StackOverflow for help, going for a walk to think through a problem, ....
And how do you also factor out time spent distracted? Or do you include that metric as well?
Personally, if we could come up with a clear definition of capturing "real-time work" into a timestamp, I would use it to simply get a better idea of how long it took me to do a task vs. how long it felt, which I'm sure I could use in a number of ways. But I wouldn't obsess over the exact values given how much my mileage varies by circumstances 😄 Nor would I consider it useful from a code history perspective.
Thanks so much for the thoughtful response. I love this. I agree that from the often used features of git the timestamps will change frequently. Like most things with working on a team a workflow would need to be agreed upon so that any kind of baseline could be established.
I also really like taking a step back to look at it from a couple of angles. Personal or individual productivity measuring is super hard and there is so much that is difficult or impossible to measure in any meaningful way. The process of measuring often is so much work in itself it takes away, or at least feels like it does, from one being productive.
This is a great example of the many ways work can be measured and the importance of a team of people agreeing on how that measuring is done and what is measured when determining how to be effective at their work.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I guess answers will be related to your view on what a git log should represent in your project: is it an accurate account of the work that was done, or a story of how the code was written? The difference is subtle but important for this discussion.
In my practice, I prefer pull request commit logs to show an accurate account of the work that was done for the sake of providing development context to reviewers. But I prefer the commit log of the project as a whole to tell a higher-level, cohesive story of how the project changed over time; as such, I am often squashing, rewriting, and reorganizing my feature branches prior to merging them into the project trunk.
Given this sort of workflow, which constantly changes commit SHAs and timestamps, I never look at commit timestamps except to determine when a bit of code was introduced to the code base, and rarely does anything more granular than "day of month of year" matter to me.
So I tend to view commit timestamps as capturing the birth of code as witnessed by the codebase rather than as an accurate representation of when it was written. From this perspective, I don't think the addition of "real-time work tracking" to the project history is useful to me most of the time.
Now, all of that said, I love the idea from a personal productivity and effectiveness angle 😍 I've thought many thoughts about ways to encode more of the human factor into commits for later analysis. It's really fascinating and also poses terrific challenges!
There's a difference between real-time work tracking for a project, and for a person. And there's a problem with how to define "work" in both cases: how do you capture/represent the effort that went into every commit? This includes rewriting, testing, debugging, begging the tiny gods of StackOverflow for help, going for a walk to think through a problem, ....
And how do you also factor out time spent distracted? Or do you include that metric as well?
Personally, if we could come up with a clear definition of capturing "real-time work" into a timestamp, I would use it to simply get a better idea of how long it took me to do a task vs. how long it felt, which I'm sure I could use in a number of ways. But I wouldn't obsess over the exact values given how much my mileage varies by circumstances 😄 Nor would I consider it useful from a code history perspective.
Thanks so much for the thoughtful response. I love this. I agree that from the often used features of git the timestamps will change frequently. Like most things with working on a team a workflow would need to be agreed upon so that any kind of baseline could be established.
I also really like taking a step back to look at it from a couple of angles. Personal or individual productivity measuring is super hard and there is so much that is difficult or impossible to measure in any meaningful way. The process of measuring often is so much work in itself it takes away, or at least feels like it does, from one being productive.
This is a great example of the many ways work can be measured and the importance of a team of people agreeing on how that measuring is done and what is measured when determining how to be effective at their work.