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?
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!
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).
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.
> 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.
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).
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?
This is awesome, and came at just the right time for me!
Last February, in my last semester of college, I heard about an iPad contracting job. I had never done any freelance work before, so I thought it would be a good opportunity to see what it was like. I gave the client a whole-project quote based on some conservative time estimates and an hourly rate a little below the market.
After that I didn't really track hours since they were paying per feature milestone, so when the project was over I had no idea how much time I had actually spent on it. I had planned to write a utility to estimate the time from my Git commits. You beat me to it! (Turns out I'm faster than I thought. :-))
I just finished writing my own time tracking tool, but I may use this instead for projects that can be represented entirely by their git repository.
Some comments:
- I have a lot of repositories, most of them small personal projects or other people's open source projects. Can you let me only import a couple, maybe preferring private and recent repositories?
- The design is very nice
- Can you separate the time estimation from the cost calculation? I'm sure a lot of people are interested in that functionality by itself.
- If I'm going to back-fill estimates, I want to see the diff, but the links to the commit diffs are on the page before you can enter the estimates. Add links to the page where you can enter your own estimates!
It has some advanced features like estimating the time spent on each line item based on number of commits or number of source changes.
For more accurate invoicing, you would utilize an app like TimeSink to record your computer's activities and then BBNW can cross reference that time spent with your git commits and figure out the billed activity that way.
Nonetheless, absolutely great job on the implementation! I had no idea anyone else was working on the same problem. If you're in the Bay area, I'd love to collaborate.
An option to only select commits with entered times would be handy rather than having to deselect the estimates and non value commits (maybe this is implemented but I didn't create a commit with a time value).
Think someone else mentioned this, but the ability to override or add time to estimated and/or non value commits.
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?