Show HN: Personal Time Tracking with Git (opens in new tab)

(doocot.sh)

16 pointsthisdougb0y ago7 comments

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.

7 comments

gerardnico0y ago

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

thisdougbOP0y ago

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.

thisdougbOP11mo ago

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 <thisdougb@users.noreply.github.com>
  Date:   Tue Apr 1 22:31:22 2025 +0100

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

jarbus0y ago

Not a git guru, but I love this.

thisdougbOP0y ago

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.

kinduff0y ago

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

1 more reply

j / k navigate · click thread line to collapse

Show HN: Personal Time Tracking with Git (opens in new tab)

(doocot.sh)

16 pointsthisdougb0y ago7 comments

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.

7 comments

gerardnico0y ago

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

thisdougbOP0y ago

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.

thisdougbOP11mo ago

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 <thisdougb@users.noreply.github.com>
  Date:   Tue Apr 1 22:31:22 2025 +0100

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

jarbus0y ago

Not a git guru, but I love this.

thisdougbOP0y ago

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.

kinduff0y ago

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

1 more reply

j / k navigate · click thread line to collapse