I am quite comfortable with `git rebase -i` and I still prefer jj. Most importantly, I get in this situation less often in the first place. Because reodering a

I am quite comfortable with `git rebase -i` and I still prefer jj. Most importantly, I get in this situation less often in the first place. Because reodering and squashing commits can be done with an easy command[1], I tend to squash or rebase as I think of it instead of batching it up to do all at once. Many times, I don't need to manually target which commit to squash into at all, because I can be editing at the tip of the branch, then use `jj absorb` to automatically squash all my changes down into the commits where they belong.[2] And `jj undo` is just easier to use than the reflog[3]. While reading the reflog you posted, I have to mentally replay each commit step by step. But really, if I messed something up, it's most likely I want to just go back to `HEAD@{31}`. `jj rebase` is atomic, so the whole thing is undone with one invocation of `jj undo`. [1]: https://docs.jj-vcs.dev/latest/git-experts/#automatic-and-safer-history-editing https://docs.jj-vcs.dev/latest/git-experts/#automatic-and-sa... [2]: https://docs.jj-vcs.dev/latest/git-experts/#jj-absorb-makes-it-easier-to-update-a-patch-stack https://docs.jj-vcs.dev/latest/git-experts/#jj-absorb-makes-... [3]: https://docs.jj-vcs.dev/latest/git-experts/#undo-is-more-powerful-than-using-the-reflog https://docs.jj-vcs.dev/latest/git-experts/#undo-is-more-pow...