Implement as a wrapper around git instead of using hooks?

[pmeinhardt]

First up: Nice work! 👏 Really looking forward to using herodot and seeing it develop!

---

I was just wondering:

How about implementing the tracking functionality by setting up herodot as a git wrapper instead of relying on post-checkout and post-commit hooks?

By "wrapper" I mean something along the lines of hub or rather the shims used in rbenv and asdf.

A few possible advantages of such an approach:

1. Allow tracking development activity for source code management tools other than git

   When creating git, hg, … shims that are prepended to one's PATH, it would be possible to intercept branch-switching and commit activity, even if the SCM tool does not provide hooks for these activities.

   Theoretically, you could instrument other tools as well using this approach – it's probably better not to go totally crazy with it though.

2. Track all repos instantly without explicitly installing hooks into each of them

   With the proposed approach, you wouldn't need to herodot track … all your repos first. Instead every call to git… could be tracked right away.

3. Allow for easier updates

   One possible problem of the hook approach is, that when you have to update the tracking logic, you will have to update the hook scripts in all tracked repos. With a shim/wrapper approach, it would be enough to update herodot itself as all the tracking logic is kept inside the tool. Doing this, you also avoid scattering the same hook code throughout all your repos.

Those are just a few thoughts. Much looking forward to feedback and discussion. I would also be happy to contribute to/pair on an implementation of the described approach 🙂

[andreasknoepfle]

Nice idea. 👍 The advantages you named are totally valid and I'd be totally in to try that out. But to start a discussion, I'd throw in some advantages of the current approach as well:

1. Tracking selectively
   • One upside of the herodot track approach (or at least explicitly naming what you want to track) is that you may not want to track every repository. Examples:
   • Working in your free-time using git will track this as well, which kinda will mess your log times a bit (lets say you work on something private at 8 a clock in the afternoon, it will assume that you worked on the work-related repo until then)
   • Some repos may not need to be tracked even in you work (I can give you an example, but as this is public I will not throw names here)

However we could probably implement a herodot track command for your approach as well, by using the .herodot.yml in a project, and explicitly enabling tracking.

2. As alternative for enabling tracking automatically, we could add something like herodot track --global or herodot auto-track or whatever, that writes git hook templates, that are used by git when cloning or initialising a repo.

3. In theory (and maybe a bit hacky) we could update the scripts of tracked repos, by using the paths recorded in the worklogs. Not a good solution, but one path we could go if we stick to the current approach and need to update the hooks.