cli split: Make jj split --parallel set @ to the first revision

[emesterhazy]

jj split --parallel now sets the working copy revision (@) to the first revision created by the split instead of the second. As a result, @ remains on the same change id before and after the split.

There is no good reason to choose the second commit as the working copy commit after a --parallel split. The only reason it works that way today is because doing that didn't require any code changes compared to the non parallel split.

Martin proposed this change in the review for #5618.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added tests to cover my changes

[yuja]

Since non-parallel split bring us to the second commit (= the state before split), it might make sense to move the working copy to a merge of split commits.

[emesterhazy]

Since non-parallel split bring us to the second commit (= the state before split), it might make sense to move the working copy to a merge of split commits.

Yeah I actually thought about that as well, but I'm not sure if that's more useful or not. If you're splitting to stash the changes out of line, sort of like git stash, then it's probably not helpful. If you just want to parallelize the commits then it is.

Curious to hear what other people think. I do like the consistency of preserving the working copy across the split.

[ilyagr]

(Tangential to this PR) I assumed that if we're talking about keeping the change id and the bookmarks at the first commit for non-parallel split, the working copy would stay there too. It seems I was wrong re #5618 , but would that make sense?

Update: We can move this discussion to #3419 (comment).

[martinvonz]

Since non-parallel split bring us to the second commit (= the state before split), it might make sense to move the working copy to a merge of split commits.

Yeah, I was also wondering if we should do that, but it's also kind of weird that it creates an additional commit. I guess it would be this:

$ jj log
o C
|
@ B
|
o A
$ jj split B
$ jj log
C
|\
| | @
+-+-'
| |
o | B2
| |
| o B1
|/
o A

It's a bit weird that we end up in a empty commit.

If we think of jj split --parallel as jj split followed by jj parallelize, we would end up with the working copy on the same commit as jj split does (which is currently the second, but we're planning to make it end up on the first commit).

[yuja]

It's a bit weird that we end up in a empty commit.

Right.

I think non-parallel split (of the working copy) has implication that the user wants to split out unfinished work, so the new commit is edited. I have no idea what is expected for parallel split of @.

[martinvonz]

I have no idea what is expected for parallel split of @.

I have used it for moving out changes that were in the working copy into a separate change.

[emesterhazy]

If we think of jj split --parallel as jj split followed by jj parallelize, we would end up with the working copy on the same commit as jj split does (which is currently the second, but we're planning to make it end up on the first commit).

Yeah, thinking about this again, the current behavior is actually fairly consistent. It might be suboptimal if people are using jj split --parallel as an analogue for git stash though.

we would end up with the working copy on the same commit as jj split does (which is currently the second, but we're planning to make it end up on the first commit).

Wait are you saying that we are planning to make jj split (non --parallel) end up on the first commit? I don't really think that's a great idea for the reason Yuja mentioned - jj split sort of implies that the second commit has some unfinished work that the user wants do edit.

[martinvonz]

Wait are you saying that we are planning to make jj split (non --parallel) end up on the first commit?

Yes, but I was just confused about all the versions we've discussed. Sorry

[emesterhazy]

If we want it to behave like jj split followed by jj parallelize, then maybe we shouldn't move @ at all since that's how jj parallelize behaves.

I agree that with Yuja that moving @ to the second commit seems useful for a normal jj split, but I'm having trouble justifying it for jj split --parallel.

As far as adding an empty child of both the first and second commit, I think it's unnecessary. If the user wants to end up in this state, they can just create the new commit before splitting its parent. As far as other workspaces go, their working copy will remain intact until update-stale is run.

If we decide to create a new empty commit to avoid updating the working copy after jj split --parallelize, then we should probably do the same for jj parallelize for consistency, and I think it's going to be more involved in that case since the working copy for a workspace can be any of the commits hit by the parallelize.