Excellent! At the moment, I dump all my TODOs in a section in my readme, but if the relate to specific lines of code, it's a mess trying to trace what the TODOs were referencing when I try to go back and work on them many months later.
Once question, once a TODO is removed from the repository, is the issue also automatically closed? Or vice-versa? Would be cool if the two were coupled, so that there aren't dangling TODOs left in the repository once the issue has been addressed in some fashion.
This coupling is not ready yet, I still have to find a satisfying workflow.
When issue is closed :
— it detects TODOs anywhere, not necessarily in comments, it could destroy some code (same for 'inject-issue' but here it would be a removal, can be tougher)
— maybe a TODO previously related to this issue will have to be modified instead of deleted, how should it handle it?
When TODO is removed :
— should I close issue directly or check in the whole codebase if it still exists somewhere and keep it open?
Many questions arise and I still found no harmless answers :(
But it definitely should help you track it both ways, with a command "stat" for example that would report you any actions you should achieve, and even interactively do it for you. But I don't think it will happen in hook itself yet.
I want all ideas available here ;) should create an issue for open discussion.
Actually, thinking about it a bit more, I think it'd be nice to be in full control of the process. So perhaps something a la "brew doctor" would be nice, so that you simply obtain an overview of disconnected TODOs and issues. That way, it's clear that there's something lingering that needs to be taken care of.
I think that any automation should affect issues and not involve directly changing code. So, it might be interesting to have a toggle to automatically close issues after scanning the repo for the presence of TODOs. I do think that this should be a toggle that can be switched on or off.
Great idea! Integrating with Githooks is super convenient.
This reminds me of watson (https://github.com/nhmood/watson-ruby) which manages TODOs pretty well (with GH support) but doesn't generate the hooks for you unfortunately.
That rocks so much. It will fit perfectly to my workflow, where I write my commit messages with "Closes #[ID]." text at the end, which actually triggers github to automatically close the issue.
If this works as advertised, this is awesome. I've always used TODOs in my projects, and haven't always used github due to employer constraints. Now I won't have to put so much effort into keeping track of open tasks.
Note that it can open or comment issues (matching based on TODO's text == issue's title), but it does not yet closes them, because I couldn't find a satisfying workflow yet (which means it may never occur).
Give it a try on a sample repository, always needing more testers !
Thanks for making this! I have been requesting this for over a year now and haven't had the time to do it myself. This will totally change the way issues are handled.
Anyway, it depends on your workflow, if you already have the right tools and habits no to lose your TODOs in your deep code, Github-Todos is obviously of no use for you!
Once question, once a TODO is removed from the repository, is the issue also automatically closed? Or vice-versa? Would be cool if the two were coupled, so that there aren't dangling TODOs left in the repository once the issue has been addressed in some fashion.