3

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?

Jace Browning
  • 2,173
  • 1
  • 15
  • 25
  • 3
    it seems to be based on a [flawed assumption that all programmers work at similar pace](http://workplace.stackexchange.com/q/21578/168 "see eg `How to communicate my own working pace?' question at TWP for why it ain't so") – gnat May 15 '14 at 18:31
  • @gnat: why would it be? You put in the time spent into the message. – scrwtp May 15 '14 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](http://programmers.stackexchange.com/a/53513/31260 "forget the flow?")_ track time spent? Shrug. [How to explain a layperson why a developer should not be interrupted while neck-deep in coding?](http://programmers.stackexchange.com/q/46252/31260) – gnat May 15 '14 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. – Gort the Robot May 15 '14 at 19:05
  • @StevenBurnap at one of my past jobs there was a tool that allowed me to track time accurately and comfortably, without distractions (like, you know, the way like one uses turn signal when driving). But it had nothing to do with commits – gnat May 15 '14 at 19:06
  • @gnat: I'm not suggesting anything. I'm saying how the feature works. – scrwtp May 15 '14 at 20:08
  • 1
    @scrwtp okay and what I'm saying is the way how the feature works is likely very counterproductive – gnat May 15 '14 at 21:13
  • @gnat: counterproductive to what? It just gives you an additional interface to use the tools you would be using anyway. If you wouldn't bump the time or setup a review when you put in your 'safety checkpoint', there's no point in you doing it through the comment. – scrwtp May 15 '14 at 22:19
  • @StevenBurnap OTOH, If you have the need to track the time of external contractors via git commit messages and do not trust their hours list without, you have a serious problem. – Thomas Junk May 03 '18 at 07:10

2 Answers2

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.

J Trana
  • 1,369
  • 9
  • 17
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.

scrwtp
  • 4,532
  • 1
  • 24
  • 29