It often makes me nervous that there's no way to undo a Discard changes action, even immediately after a possible mistake.
It would be best if this worked in the middle of a series of Discards, Stages, and Unstages, so that you can rewind to a stable point after realizing things had gotten complicated, or that an early error occurred. I think this would require supporting undo/redo for all 3 of these operations, interleaved. Undo/redo for staging is also convenient to have even though Stages/Unstages are not destructive.
There are clearly some non-trivial issues to consider with external changes to files and/or staging if the changes "conflict". Perhaps Fork could throw up its hands if it detects such cases with a popup saying it can't for that reason (or perhaps there are some cases where it can do the right thing.)
Q: One Undo stack per project (flipping context to another file and making a change there if you undo more), or one per file? One per project seems needed, especially to get back to a file if you Discard the last change.
(This is a bit different from #981, which in my mind is about reverting git operations like commits and pulls. #981 is perhaps more related to the reflog, and if implemented I'd consider using git's words rather than Undo to refer to those operations. For a discard, Fork is acting as an editor application, so this is a more straightforward use of the word Undo in the context of the Fork app/Cmd-Z.)
It often makes me nervous that there's no way to undo a Discard changes action, even immediately after a possible mistake.
It would be best if this worked in the middle of a series of Discards, Stages, and Unstages, so that you can rewind to a stable point after realizing things had gotten complicated, or that an early error occurred. I think this would require supporting undo/redo for all 3 of these operations, interleaved. Undo/redo for staging is also convenient to have even though Stages/Unstages are not destructive.
There are clearly some non-trivial issues to consider with external changes to files and/or staging if the changes "conflict". Perhaps Fork could throw up its hands if it detects such cases with a popup saying it can't for that reason (or perhaps there are some cases where it can do the right thing.)
Q: One Undo stack per project (flipping context to another file and making a change there if you undo more), or one per file? One per project seems needed, especially to get back to a file if you Discard the last change.
(This is a bit different from #981, which in my mind is about reverting git operations like commits and pulls. #981 is perhaps more related to the reflog, and if implemented I'd consider using git's words rather than Undo to refer to those operations. For a discard, Fork is acting as an editor application, so this is a more straightforward use of the word Undo in the context of the Fork app/Cmd-Z.)