I’ll hop on the train and say that I’ve been using jj recently as well, and it’s given me that feeling of safety and freedom I got when I first started using version control 10 years ago. That sense that “well this is a crazy idea but I’ll just commit now and try it, I can always roll back”.
Any of them. All of them. (Maybe not remote changes, but that's way less safe to attempt, even if possible.)
Which is what `jj undo` does, and why I brought it up.
I'm well aware git doesn't have a unified concept of undoing, but I'm equally aware that it's possible. (Even before jj, GitUp and git-branchless offered universal undo.)
Not to mention Git has a reflog, so `undo` could just always revert the last operation in the reflog. Or the last `n` operations if specified. So there already is a universal list of what operations were performed, and thus what operations for `undo` to work on.
Git always baffled me with revert - I learned early on that if I wanted to “undo” something, the best bet was to either branch from a commit before the thing I want undone, and maybe rebase/cherry pick later commits, or just start over.
This seems like the ideal case for revert, but the way that it alters the history stings - the fact that reverting a commit essentially means that said commit can’t show up later as a change is frustrating - also I’m sure it’s a case of user error, but…”merge branch, realize there’s a big oops in there, revert, fix the oops on the branch” feels like it shouldn’t result in a state where git doesn’t accept the branch as mergable.
