Like? This isn't explained, I'm curious on why I would want to use it, but this is just an empty platitude, doesn't really give me a reason to try.
You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.
This is not contrived — this is an entirely realistic scenario that I use jj to handle all the time.
You could also keep the rebased commits, abort the rebase, rebase the already rebased commits and then continue the first rebase.
I would consider the first workflow to be impossible to do by most mere mortals in Git [1]. Meanwhile in jj it's downright trivial.
[1] There technically is a way to do this by setting a temporary branch, aborting the rebase, starting another rebase -i, carefully editing the interactive instructions, going to commit 8, editing that commit, then cherry-picking 9-15 from the temporary branch. But it's too hard to do in practice, and far too easy to get wrong.
That's what I've described?
> rebase -i, carefully editing the interactive instructions
You neither need to use interactive rebase nor carefully edit, since there is rebase --onto.
> But it's too hard to do in practice, and far too easy to get wrong.
I do this often it's not more complicated then any other rebase.
What is annoying in Git is rebaseing across multiple merges while forging committer and date information. Can JJ do that better?
I'm glad you don't find it too difficult to do. It's a workflow that seemingly works well for you!