git rebase -i is not that scary

Highly relevant from a few days ago https://lobste.rs/s/nprldj/git_absorb_git_commit_fixup_automatic

I'm a bit confused, the first time I saw git rebase -i (a long time ago) I was delighted! I use it most often to fixup an earlier commit with something extra that I forgot. Yes, the conflicts are occasionally annoying, and I've been in situations where a merge is much easier than a rebase because the every commit would touch the conflicting area, so you'd have to re-fix the same (but not quite exactly the same) conflict for every commit in the rebase. But it's not like it's complicated conceptually.

I think interactive rebase gets its reputation partly from how difficult it is to experiment with it. It has two major problems: it's difficult to try things out step-by-step, and so get a feel for what's going to happen next; and it's difficult to undo things once they've happened and something goes wrong.

For the first issue, there is in theory the ability to abort at any time, but in practice git only gives you an easy opportunity to abort if something goes wrong. The rest of the time, it will try to run the rebase to completion. What would be more helpful would be a truly interactive mode where you can step through each change and see the result of each line before deciding to go ahead or abort. But that's a much more complicated UI, and probably not so appropriate for git itself.

For the second issue, there is always the reflog, but the reflog is a pain to use. First you've got to understand what it's actually showing, and then you've got to find the commits you're actually interested in (not necessarily trivial partway through a complicated rebase). Then you have to actually reset your state back to that commit, which is way more involved than you'd think, in part because (iirc) there's still no way of trivially moving branches back and forth between commits.

Once you're familiar with what's going on, interactive rebase is a really nice tool for dealing with an entire branch of commits all in a single batch. For advanced usage, that batchability is a nice feature to have. But I think JJ does this better by concentrating on the non-batch case first, which is a lot easier to understand and makes experimentation a lot easier - each change is separate and the log and repo can be inspected before and after; and undo is always just a single command away and behaves exactly how you'd expect an undo to behave.