FR: Allow splitting into more than just two changes

[kastl-ars]

Is your feature request related to a problem? Please describe.
Say I have a large change, which needs to be split. With jj split currently I would need to rerun the command multiple times to split this up into more than just two changes.

Describe the solution you'd like
Adding a new CLI option for jj split, that just ask the user after the first selection of changes, if she wants to split the change any further.

Calling jj split without this option gets the current behaviour of only splitting once.

Calling jj split with the new option starts a split as usual, but after selecting the changes it pops up a question like "Do you want to split up the change any further?". If the user selects no, it is done.

If the user selects yes, split is being called again on the "originating" change (the one the changes are being split from) and the procedure starts again.

Describe alternatives you've considered
One alternative would be to just keep the current implementation and have the user rerun the command multiple times to achieve the same.

Another, more intrusive implementation could be to not just select changes (using the space key) but rather select them using numbers (0, 1, 2, 3) to put them into the respective commits. Not sure how intuitive this would be (which commit is 0?) and if it is worth the effort.

Another alternative would be some kind of TUI that allows making the decisions completely in the TUI. I think this is the most effort and I do not think it is worth it.

[martinvonz]

Calling jj split with the new option starts a split as usual, but after selecting the changes it pops up a question like "Do you want to split up the change any further?". If the user selects no, it is done.

Another option is to do what hg split does: if the user selects all changes, then it means they don't want to split further.

[arxanas]

See also arxanas/scm-record#73 for implementing it in the TUI for the built-in diff editor. (It is indeed involved, but I think would be a desirable end state.)

[kastl-ars]

Calling jj split with the new option starts a split as usual, but after selecting the changes it pops up a question like "Do you want to split up the change any further?". If the user selects no, it is done.

Another option is to do what hg split does: if the user selects all changes, then it means they don't want to split further.

Maybe I am mixing this up with the squash workflow or I am missing something, but during the "first" split I can select/deselect changes. Selected ones go into a new changes, deselected ones stay (or the other way round). How would I show that I want the changes to go to more than two changes?

[arxanas]

Maybe I am mixing this up with the squash workflow or I am missing something, but during the "first" split I can select/deselect changes. Selected ones go into a new changes, deselected ones stay (or the other way round). How would I show that I want the changes to go to more than two changes?

In this case, you would make a selection for the first change, and then the "remainder" is what could go into the second or later changes. You continue until the "remainder" is empty.

• To indicate that you're "done", you have to actually select all of the changes so that there's no "remainder".
• Therefore, at each step, you make a small commit with a subset of the changes, until you eventually would create an empty commit, at which point you stop instead.

[emesterhazy]

This is something I've missed coming from Mercurial, and I'd be happy to see it implemented.

Doing what hg split does is the simplest solution, and in practice I think the workflow is pretty nice. We could do this directly in jj without any changes to scm-record since you simply invoke the diff tool continuously until the user has selected all of the changes.

The suggestion in arxanas/scm-record#73 is also interesting. I don't have the context of how Meta's tool works, but the workflow sounds a bit like an interactive rebase tool. If we go this direction it seems like we might still need changes to support continuous splits for external diff tools.