DarkyenusTimeTracker
DarkyenusTimeTracker copied to clipboard
Question: Traking project with multiple Modules
The case is I have project which bundles multiple repos in one. So there is bundle GIT repo which dowloads others repos to itself. When I commit, I'm commiting to concrete GIT repo, but this plugin only track time of Bundle GIT repo, but didn't recognize sub-repositories. Is there any way how to enable support for those type of composite project? What must to be changed to make this setup work properly?
For now only way it seems possible is to have IDE instace for each sub-repo. But in that case I lost advantage of using composite project. Like docker-compose, global env etc.
The time counter is currently on the IDE project level and git integration is not built for anything more complex. There is currently no way to track the time with granularity of a git repo (in a single IDE project), as that would require the plugin to be much more complex than it is.
However, if you don't mind that the counter would still be at the IDE project level, you could probably setup all your internal git repos to inject the time using the main counter by setting up the git hooks manually. The main git repo contains the prepare-commit-msg hook to do the time injecting (at /.git/hooks/prepare-commit-msg
). If you add this hook to all relevant repositories, it may do what you want.
If you do this, don't forget to change the path to the time file of the copied hooks. It is on line 42 (RELATIVE_DTT_TIME_PATH
variable) and the time file is at /.git/.darkyenus_time_tracker_commit_time
.
So if the bundle repo contains the line RELATIVE_DTT_TIME_PATH="../.darkyenus_time_tracker_commit_time"
, a sub repo in directory /my-sub-project
will have that line be RELATIVE_DTT_TIME_PATH="../../.git/.darkyenus_time_tracker_commit_time"
.
The only downside to this approach is that these hooks are not managed by the plugins, so disabling the git integration will not remove them, and that they must be updated manually if the plugin template significantly changes in later versions. Otherwise I don't see any reason why it shouldn't work.
If this is something that fits with your workflow, despite its limitations, I'll consider giving it a proper support in the future versions.
Thanks for exhausting answer. I will try the way with manual override of the hooks.