Using sqitch rework in practice

[angererc]

Hi, I have two questions regarding how to use sqitch rework in practice:

1. For example, when fixing a bug, it's not necessarily clear to me initially what file(s) I will need to change. E.g., maybe I try something in file A, then file B until I settle on a solution. git keeps track of the changes compared to the last commit. However, sqitch doesn't and if I sqitch rework file A, then the tagged copy of A will also have the new code, not the old. Is there a way to tell "sqitch rework" to tag the file that was last checked into git or something? Or how do people handle this issue?
2. Is there a way to tell sqitch rework to store the tagged versions somewhere else? Having all the tagged copies in the same folder really clutters up the file view in the IDE (I'm using VS Code). It would help if every tag gets its own subfolder with the tagged deploy/revert/verify scripts, for example. Or how are people dealing with dozens of myfile@tag123 copies in their source folders?

Thanks!

[theory]

HI @angererc, thanks for your questions!

1. Not currently, no. I'd like to see a lot more source code management integration in Sqitch for stuff like this; I can imagine at the very least it giving a warning and doing nothing if you try to rebase a file that's already modified. For now, I personally tend to do experimental work to figure stuff out in a completely separate file and then, once I've figured out what I need to do, rework changes in a clean repo.
2. Yes! Check out the reworked_dir configuration option in the config docs.