I haven’t tried jj yet, but from my reading of the article, 80% of the problem is that jj split is backwards for some (most?) uses. You seem to want to split a change such that the newly split piece goes before the part you leave alone, and jj split wants to do the opposite.
Certainly when I split a change up in git or hg, I’m usually trying to break off a piece that goes before the rest. TortoiseHG’s committer works like that — you select the parts to commit, and the rest stays uncommitted in the working copy.
So maybe the only tooling needed to make jj better is a mode (or maybe a default) that reverses the initial guess as to which parts of the change go where.
Might have been a lack of clarity on my part. When you split, you are actually choosing "what goes first". The issue workflow-wise today is primarily a lack of tooling designed to represent this process visually in an easy way.
If I understood correctly, the problem is that the default is that everything “goes first” and you have to remove the hunks you want to go second. As if in a Git tool everything defaulted to “staged” and you had to click “unstage” on what you want to go second, which is the reverse of what they all do.
Except…when you’re actually splitting an existing commit with interactive rebase, don’t Git tools make you unstage changes that should go second? I see how it’s backwards and annoying compared to “git add -p” for a new commit, but they seem equally bad for splitting existing ones.
Certainly when I split a change up in git or hg, I’m usually trying to break off a piece that goes before the rest. TortoiseHG’s committer works like that — you select the parts to commit, and the rest stays uncommitted in the working copy.
So maybe the only tooling needed to make jj better is a mode (or maybe a default) that reverses the initial guess as to which parts of the change go where.