3 ms·

As the resident "I want my commits to be beautiful" purist around here, I have to say that I really, really dislike this idea. Commits are rarely exactly bound

by pilif 15y ago

As the resident "I want my commits to be beautiful" purist around here, I have to say that I really, really dislike this idea. Commits are rarely exactly bound to a specific billable item on an invoice. Implementing a feature could and often does cause mutliple commits. A system like this either encourages to mush everything together into one commit (bad) or it creates basically empty or non-related commits after implementing the feature so it appears on the invoice. But this is just me. I see how this could be useful for people who are not such purists as I am. On the other hand: In my SVN times, I would have used a service like this in a heartbeat. Even in my early git days. But after learning about optimizing commits and about the beauty of a clean history, I now changed my mind about this. So ask yourself: Is there any chance you might shift in your thinking about the commit history? If yes, do you really want to have commits in your history that you might at one day consider to be really bad ones?

nhocki 15y ago
I know that most of the times (ok, all of the times) you'll have more than one commit for any feature you develop. We'll have a small gem or something to do that. You'll start your work and we'll track your time and at the end make a commit with the time stamp (or use git notes to keep the commits clean). All the commits you do in that time will be "ignored". We don't have this now because we didn't have the time to do this (48 hours is not that much you know). Thanks for the feedback anyway. Well have your comments in mind when developing v2 and the gem.
- pilif 15y ago
  > We don't have this now because we didn't have the time to do this (48 hours is not that much you know). I didn't intend to bash on your project. I'm sorry if my comment read that way. I was just saying that I, personally, would not want my commits to be tied to an invoice that is most likely going to be read by a non-coder because that would severely hamper the quality of my commits. I do believe though that for other people this might not be as much of an issue - heck it probably wouldn't for me if I were working on different stuff than I'm working on right now. I just wanted to inform the people here not to jump to conclusions but think what this integration might (or might not - depending on their situation) do to their commits. I LOVE it when people like you have a cool idea and follow through; whether the result is usable for me or isn't.
  - nhocki 15y ago
    Oh no, no "offense" taken. We really appreciate feedback (all of it). Having people disagree with the app forces us to make it better. About the messy commit messages, that's why git notes may help (keeps your commits clean, but you still don't have to write the invoice entries again and again). Thanks! :-)
gexla 15y ago
I agree. I don't think my clients would appreciate adding time tags to each commit. It's nonessential information which is better placed in a different system, referencing the commit if needed. Once the invoice has been taken care of, the time tags become meaningless while the rest of the information is still very important. I would rather my history always stay clean. Another issue is that when you start down this road, where does it end? You start out with time, and then you might start thinking about what other nonessential information you could put in there. Each commit might then start looking like a config file for your swiss army approach to using Git as a project management tool. I think there still could be a use for this. It could still import the commits into a time tracking system for convenience. Props to the developer though. Everyone is free to make their own decision and some developers will love this. Edit: I just saw the reply which suggested possibly using git notes. I didn't even know about git notes. I will check that out, thanks!
foz 15y ago
I agree that commit messages should be clean and relate to the code. I would not want to see time logs attached to commits for many reasons. Perhaps another idea might be to attach the time log entries using git-notes. Maybe this would allow time to be tracked in git, on a per-commit basis, but not pollute the commit messages?
brainlock 15y ago
The pollution comes IMHO not only from having the timestamps in the commit (and to fix that the idea of using git-notes that came up in a sibling comment seems to be a perfect fit), but more from trying to put too much in a single commit. This could easily be fixed by using a feature branch, do nice self-contained and easy to read commits in the branch, then attach the time-logging and billing information to the merge commit (using git-notes).

by pilif 15y ago

nhocki 15y ago

I know that most of the times (ok, all of the times) you'll have more than one commit for any feature you develop. We'll have a small gem or something to do that. You'll start your work and we'll track your time and at the end make a commit with the time stamp (or use git notes to keep the commits clean). All the commits you do in that time will be "ignored". We don't have this now because we didn't have the time to do this (48 hours is not that much you know). Thanks for the feedback anyway. Well have your comments in mind when developing v2 and the gem.

pilif 15y ago
> We don't have this now because we didn't have the time to do this (48 hours is not that much you know). I didn't intend to bash on your project. I'm sorry if my comment read that way. I was just saying that I, personally, would not want my commits to be tied to an invoice that is most likely going to be read by a non-coder because that would severely hamper the quality of my commits. I do believe though that for other people this might not be as much of an issue - heck it probably wouldn't for me if I were working on different stuff than I'm working on right now. I just wanted to inform the people here not to jump to conclusions but think what this integration might (or might not - depending on their situation) do to their commits. I LOVE it when people like you have a cool idea and follow through; whether the result is usable for me or isn't.
- nhocki 15y ago
  Oh no, no "offense" taken. We really appreciate feedback (all of it). Having people disagree with the app forces us to make it better. About the messy commit messages, that's why git notes may help (keeps your commits clean, but you still don't have to write the invoice entries again and again). Thanks! :-)

gexla 15y ago

I agree. I don't think my clients would appreciate adding time tags to each commit. It's nonessential information which is better placed in a different system, referencing the commit if needed. Once the invoice has been taken care of, the time tags become meaningless while the rest of the information is still very important. I would rather my history always stay clean. Another issue is that when you start down this road, where does it end? You start out with time, and then you might start thinking about what other nonessential information you could put in there. Each commit might then start looking like a config file for your swiss army approach to using Git as a project management tool. I think there still could be a use for this. It could still import the commits into a time tracking system for convenience. Props to the developer though. Everyone is free to make their own decision and some developers will love this. Edit: I just saw the reply which suggested possibly using git notes. I didn't even know about git notes. I will check that out, thanks!

foz 15y ago

I agree that commit messages should be clean and relate to the code. I would not want to see time logs attached to commits for many reasons. Perhaps another idea might be to attach the time log entries using git-notes. Maybe this would allow time to be tracked in git, on a per-commit basis, but not pollute the commit messages?

brainlock 15y ago

The pollution comes IMHO not only from having the timestamps in the commit (and to fix that the idea of using git-notes that came up in a sibling comment seems to be a perfect fit), but more from trying to put too much in a single commit. This could easily be fixed by using a feature branch, do nice self-contained and easy to read commits in the branch, then attach the time-logging and billing information to the merge commit (using git-notes).