Nice idea. I like the “local-first, no account” approach, especially for something as sensitive as time tracking.
Auto-detecting the project from the git repo feels like the right level of magic to me. It removes friction without hiding what’s going on, which is usually the hard balance to strike in CLI tools.
One thing I’d be curious about is how it handles context switches within the same repo, or work that isn’t tied to a directory at all (meetings, research, etc.).
Overall, this feels very much in the spirit of Unix-y tools: small, focused, and composable.
I'm thrilled that the Unix-y approach resonates with you, as that is exactly what I am aiming for!
And yes, you have hit the main tradeoff that I have and am currently struggling with. The auto-detection works great for "I'm in X project, working on X," but it doesn't work well for the exact cases you mentioned.
Right now, this is how I handle these types of scenarios:
1. Context switches in the same repo: I use the description field to differentiate:
`tmpo start "Refactoring auth module"`
`tmpo start "Fixing CSS bugs"`
This has the same project name but with different descriptions. When you export for invoicing or just personal statistics, you can see this breakdown.
2. "Non-directory work" (meetings, research, etc): I use `tmpo manual` to create entries after the fact.
`tmpo manual` (opens interactive prompt for project/time/description)
Or I just run `tmpo start "Team standup"` from wherever I am and let it tag to whatever directory I'm in. This is obviously a bit janky.
To be honest, I am still working on solving this problem. I optimized for what I think is most "solo dev working in project directories" because that is my workflow; however, I'd love to get more feedback and contributors to help make it work for others!
A feature I am also working on currently is a category/phase system that can significantly improve tagging time entries.
What is your current workflow? Do you switch contexts within the same repo often, or is the non-directory work the bigger pain point?
Nice idea. I like the “local-first, no account” approach, especially for something as sensitive as time tracking. Auto-detecting the project from the git repo feels like the right level of magic to me. It removes friction without hiding what’s going on, which is usually the hard balance to strike in CLI tools. One thing I’d be curious about is how it handles context switches within the same repo, or work that isn’t tied to a directory at all (meetings, research, etc.). Overall, this feels very much in the spirit of Unix-y tools: small, focused, and composable.
Thank you!
I'm thrilled that the Unix-y approach resonates with you, as that is exactly what I am aiming for!
And yes, you have hit the main tradeoff that I have and am currently struggling with. The auto-detection works great for "I'm in X project, working on X," but it doesn't work well for the exact cases you mentioned.
Right now, this is how I handle these types of scenarios:
1. Context switches in the same repo: I use the description field to differentiate: `tmpo start "Refactoring auth module"` `tmpo start "Fixing CSS bugs"`
2. "Non-directory work" (meetings, research, etc): I use `tmpo manual` to create entries after the fact. `tmpo manual` (opens interactive prompt for project/time/description) To be honest, I am still working on solving this problem. I optimized for what I think is most "solo dev working in project directories" because that is my workflow; however, I'd love to get more feedback and contributors to help make it work for others!A feature I am also working on currently is a category/phase system that can significantly improve tagging time entries.
What is your current workflow? Do you switch contexts within the same repo often, or is the non-directory work the bigger pain point?