[naholyr]

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.

[kartikkumar]

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.

[naholyr]

That's more the direction I think about yes

[greyskull]

I'm just throwing out an idea here; I don't know if it's possible.

Put some sort of tag in the todo comment to represent a change. e.g. // TODO: Fix this issue #complete

At commit time, the hook will see the tag changed, reference the commit in the issue, and then auto-close it.