I initially thought the same but have come around. The problem at this point is the lack of tooling that understands and supports it. You could, quite reasonably, say they should have made a different choice based on what works best with tooling today, and that would be fair; but I think that would leave us in a bit of a local maximum. My hope is that if and as it catches on, tools will grow feature and modes to work with it—just like they did to work with Git’s index.

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.