Show HN: Personal Time Tracking with Git

[thisdougb]

I've been trying to figure out how long feature development takes, for years. I'm not a fan of (a priori) estimations of work, which just seem like the wrong measure. I think I've got a better way.

Genuinely interested if some git gurus can improve this. Particularly around the pre-push hook, which is dependent on retained squash commit text. Or if there's an entirely better way to achieve the same thing.

[gerardnico]

Instead of creating a tag, you could add the time in your commit message as a footer key following the conventional commit spec.

https://www.conventionalcommits.org/en/v1.0.0/

Ie example of commit message

fix: prevent racing of requests

Desc

Time-spend: Z

[thisdougb]

I did look at modifying the merge commit message, but I couldn't figure out how to accurately detect a merge commit.

Having re-looked, I just found 'git rev-parse --verify MERGE_HEAD' which may help here. Time to do some testing. It would be good to clean up and standardise the commit msg itself too. Thanks.

[thisdougb]

cool.

The prepare-commit-msg hook is the one. One of the hook args is the type of commit (merge, squash, etc). And the merge commit msg files exist (SQUASH_MSG, MERGE_MSG) so my original logic all works.

  $ git log -1
  commit 735ce5f9998736c4066d63ab851df2023640dad5 (HEAD -> master)
  Author: Doug Bridgens <[e-mail]>
  Date:   Tue Apr 1 22:31:22 2025 +0100

        test4 does some stuff
    
    Time spent on feat_test4: 0d:0h:7m secs=426

[jarbus]

Not a git guru, but I love this.

[thisdougb]

thank you.

I'm trying to workout how it (the idea) can be ported to work with GitHub pull requests. But I don't know enough about what's happening under the hood with GitHub during the PR process.

[kinduff]

have you explored what you can do combining your info with what you can get with their cli?

[thisdougb]

ah, I totally forgot there was a cli tool for gh. thanks. I'll have a dig around and see what I can get from it.