Show HN: Personal Time Tracking with Git
16 thisdougb 7 3/29/2025, 10:05:07 AM doocot.sh ↗
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.
https://www.conventionalcommits.org/en/v1.0.0/
Ie example of commit message
fix: prevent racing of requests
Desc
Time-spend: Z
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.
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.
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.