Show HN: Personal Time Tracking with Git
doocot.shI'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. 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 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. 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. Not a git guru, but I love this. 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. have you explored what you can do combining your info with what you can get with their cli? 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.
$ 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