In this article
Aider uses ordinary Git commits and separates preexisting dirty-file work; undo must be understood against the actual current history.
Aider’s Git integration can create ordinary project commits, including a separate commit for preexisting dirty-file changes before editing them. Inspect that boundary before using /undo; the latest assistant turn is not a reliable description of every change already in the repository.
The concrete application boundary
Unlike a shadow workspace snapshot, an Aider commit belongs to the project’s Git history. The documented integration commits edits and takes special care with dirty files by committing their existing changes first. This separates user work from assistant work, but it also means a session can change history before the requested correction is complete. Start by inspecting the repository yourself. Determine which changes are yours, which files are needed for the task, and whether automatic commit behavior matches your intended workflow. The model provider has no authority to decide that unrelated user edits should be discarded. A local generation connection does not change Git ownership or make all actions reversible (Aider Ollama integration).
A practical route
Before the session, inspect status and the current diff with your normal Git tools. Save or commit user work deliberately where appropriate. Start Aider in the intended repository and add only the files required for the task. After an edit, use /diff to inspect changes since the last user message and inspect the ordinary Git log for commit boundaries. The documented /undo command discards the last change; verify what that means for the current history before invoking it. /commit and /git expose other Git operations and should not be treated as interchangeable with undo (Aider Git integration).
A worked example
A developer has manually corrected a comment in a helper, then asks Aider to change one fallback label in that same file. The integration may first commit the dirty comment correction separately, followed by the assistant edit. A rejected fallback should not erase the earlier user correction. Inspect both commits and the file diff rather than assuming the whole file belongs to the latest prompt.
| Check | Record |
|---|---|
| User work | The preexisting comment correction visible before the session. |
| Assistant work | The fallback edit and its corresponding project commit. |
| Undo target | The exact last change being discarded, identified from the current repository history. |
Reading the failure correctly
A clean status after an edit may mean changes were committed, not that no edit occurred. A failed test may also predate the assistant’s commit. Keep these observations separate. Git undo does not reverse arbitrary external effects of commands, so inspect any action that wrote outside the repository independently (Aider chat modes).
What completes the check
The safe review unit is the actual commit and diff, not the assistant’s narrative about ownership. Preserve a clear separation between user changes and generated changes throughout a local Aider session.
Related background: Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.