Aider-AI
/redo would be great as I changed my mind about /undo
I have "live page reload" going and sometimes I regret my /undo decision :-O
I find more fine-grained control useful. I keep VSCode open at the same time I'm using aider. I use the diff view in VSCode's version control tab.
For aider, I actually use the --no-auto-commits flag, and then manually commit each time.
However, you could keep the auto commit on and if you regret anything, you could
git checkout HEAD~1 --soft
This moves your branch pointer back one commit (to HEAD~1) but leaves all the changes from that commit in your working directory and staging area as uncommitted changes. This allows you to make adjustments or re-commit the changes as needed without losing any work.
I prefer using full version control tools in this way because I can pick and choose what I want to keep, and easily make manual edits at the same time. VSCode has handy Stage Block/Revert Block buttons that you can use for this.
If you did it the way I'm suggesting, undo could be implemented with git stash
Step 1: aider auto commits the change
Step 2: if you don't like it you git checkout HEAD~1 --soft - this will keep the uncommitted changes in your workspace, you can pick and choose
Step 3: for a full "undo", git stash will remove the changes from your workspace
Step 4: for "redo", git stash apply will bring the changes back, ready for you to commit
I think this is better than a simple undo/redo, because often I find I want to pick and choose what I want to keep.
For git, I found these resources handy: https://learngitbranching.js.org/ https://ndpsoftware.com/git-cheatsheet.html#loc=index
redo could be implemented without keeping the commit or relying on git, if aider could keep the last iteration(s) in memory, and just reapply them
I'm a newcomer to Aider, so take my +1 with a grain of salt, but I was expecting to find such functionality paired with /undo when I started working with it. I will try the workflow detailed by @lockmeister with --no-auto-commits, and update the issue if I still feel this is necessary.
Offtopic: @paul-hammant your name seemed familiar -- I recently made a presentation about Dependency Injection in Python, and your work and presentation on PicoContainer as well as other content documenting the early days of Dependency injections origins was helpful to me. Thank you for taking the time to document it and keep it online!
I love the auto-commits. Even of my own half-finished bit. Aider and the LLMs try to reverse engineer my intention for the commit message, without being derisory, then apply the commit of the prompt. At times I fear it has gone away. I've recently tried Claude.console (I wish products had distinct names - it is difficult to follow the nouns sometimes on Reddit) and feel I'm happy to come back to Aider for the commit & /undo workflow that my pair-programming TDD mind likes. I would love --extra-auto-commits :)
He he - DI sure was a thing way back. I think in Java-land the problem was that the Enterprise-Java-Beans and Servlet tech you could create classes for (part of a larger app) that were nowhere near the main() method or a primordial entry-point for the JVM. @gbracha had insights in his blog some 18 years ago which were spot on, but it took me a while for them to sink in. As it happens (with Aider) I made a web-framework https://github.com/paul-hammant/tiny that doesn't use DI for acquiring deps - instead it uses the contextualized lookup that I was pushing before I pushed DI - https://paulhammant.com/files/JDJ_2003_12_IoC_Rocks.pdf (JDJ article that's otherwise gone from the web).