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!
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).
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.
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.
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! :-)
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?
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?