4

Some products can parse a special syntax in commit messages to extract additional data, such at time tracking information: https://confluence.atlassian.com/display/FISHEYE/Using+smart+commits

To me, this seems like the misuse of one tool to activate a feature on another, but I'm having trouble articulating my reasoning. It seems similar to the process smell of storing issue tracking information in code comments.

Is there anything fundamentally wrong with using commit messages as a time tracking mechanism?

9
  • 4
    it seems to be based on a flawed assumption that all programmers work at similar pace
    – gnat
    Commented May 15, 2014 at 18:31
  • @gnat: why would it be? You put in the time spent into the message.
    – scrwtp
    Commented May 15, 2014 at 18:51
  • 1
    @scrwtp so, you're suggesting that during few hours of brain-frying debugging / design session possibly filled with dozen of small "safety checkpoint" commits at totally random times and crowned (or maybe not) by that long awaited final commit that seems to be working as intended (hooray!) - that during all of that I am expected to also track time spent? Shrug. How to explain a layperson why a developer should not be interrupted while neck-deep in coding?
    – gnat
    Commented May 15, 2014 at 19:03
  • @gnat If you are paying contractors by the hour, it is nice to have simple ways of tracking their time. This doesn't mean that you're tracking their productivity.
    – user53141
    Commented May 15, 2014 at 19:05
  • 1
    @scrwtp okay and what I'm saying is the way how the feature works is likely very counterproductive
    – gnat
    Commented May 15, 2014 at 21:13

2 Answers 2

6

I've seen this feature as well, and am also wary of it. If I were to articulate my reasoning, I would say that it muddies the cleanness and intent of a commit message. When I ask myself, "what is the intent of a commit message?", it is to act as a succint breadcrumb to myself and others about what I was working on and how I tried to make it better.

To that end, a commit message with an issue number is actually a good thing because both I and another programmer could definitely care about that and use it for reference. Having just an issue number with no description is not particularly helpful without the issue tracking tool, so I try to avoid that and still keep at least a short description. Having an issue number even without access to the bug tracker could still help my eye easily pick out related commits.

But time tracking? Six months from now, that will not benefit me or another programmer. Additionally, it will make the commit log look messy.

1

I don't see anything wrong with it, as long as it doesn't obscure the original purpose of commit messages - saying what the change is about. If you use those tools, why would you have anything against them being better integrated with each other?

If you get your CI integrated with the repository, so you can follow a single link from a broken build to the changelist that caused it, and from there to the issue ticket and code reviews of the change, it's simply a convenient shortcut for stuff you'd have to look up yourself anyway. I think we can agree on that.

This feature just takes it a step further. And while I wouldn't care that much for time tracking - it's not like it takes that much time to do it manually - creating or updating a review with a single line would be great.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.