FR: Allow parallelize to work with groups of commits

[thirtythreeforty]

Is your feature request related to a problem? Please describe.
I frequently build long sets of commits, then decide to rebase them in a particular order and group them into several PRs which are all in parallel. That is, I start with:

A - B - C - D - E - F - G

and want to turn it into:

A - B - C \ 
            - G
D - E - F /

With Git, this is accomplished by some irritating git rebase -i invocations. With jj, it looked like jj parallelize did exactly what I was wanting, but it turns out the behavior is exactly backward from this workflow: you can pass multiple revsets, but if you do, the commits within each revset will be parallelized separately.

Here's an actual example:

[ghilliar@dev-dsk-ghilliar-1d-de44517b test]$ jj
@  lkqwwrly [email protected] 2025-01-09 17:47:45 bad2ebf1
│  (empty) (no description set)
○  yrnzyopp [email protected] 2025-01-09 17:47:42 9eccf9a4
│  (empty) (no description set)
○  uswywnzm [email protected] 2025-01-09 17:47:42 3c267137
│  (empty) (no description set)
○  xuusztrs [email protected] 2025-01-09 17:47:41 333b5384
│  (empty) (no description set)
○  tsxnqlvt [email protected] 2025-01-09 17:47:41 75fbd1ef
│  (empty) (no description set)
○  zxntrtlp [email protected] 2025-01-09 17:47:41 c41f64ba
│  (empty) (no description set)
○  oowtnoln [email protected] 2025-01-09 17:47:40 5674c0ac
│  (empty) (no description set)
○  ykurxook [email protected] 2025-01-09 17:47:35 e1e994c9
│  (empty) (no description set)
◆  zzzzzzzz root() 00000000

Describe the solution you'd like

$ jj parallelize yk..t x..l

Note how this is backward from what I am hoping for: each commit within the groups I gave is a sibling; I wanted the groups to be siblings of each other.

@  lkqwwrly [email protected] 2025-01-09 17:47:54 11d62b94
│  (empty) (no description set)
│ ○  yrnzyopp [email protected] 2025-01-09 17:47:55 d1843e21
├─╯  (empty) (no description set)
│ ○  uswywnzm [email protected] 2025-01-09 17:47:56 e65838f2
├─╯  (empty) (no description set)
○      xuusztrs [email protected] 2025-01-09 17:47:56 6f0f5687
├─┬─╮  (empty) (no description set)
│ │ ○  tsxnqlvt [email protected] 2025-01-09 17:47:55 6c7a0399
│ │ │  (empty) (no description set)
│ ○ │  zxntrtlp [email protected] 2025-01-09 17:47:56 bb36245d
│ ├─╯  (empty) (no description set)
○ │  oowtnoln [email protected] 2025-01-09 17:47:40 5674c0ac
├─╯  (empty) (no description set)
○  ykurxook [email protected] 2025-01-09 17:47:35 e1e994c9
│  (empty) (no description set)
◆  zzzzzzzz root() 00000000

Describe alternatives you've considered
It could be a flag for jj parallelize (--groups?): I don't know how useful the current behavior is considered (I'm a new user).

Parallelizing the individual desired tip revisions has no effect, but perhaps it could automatically grab revisions between the indicated ones:

$ jj parallelize t l
Nothing changed.

Version info

$ jj --version
jj 0.25.0-041c4fecb77434dd6720e7d7f1ce48d9575ac5f7

[thirtythreeforty]

I have just discovered that the desired workflow can be accomplished by judicious use of rebase:

$ jj rebase -s 'all:yk|x' -d z

This works because rebase also automatically rebases child commits of the one(s) named in the revset. all: is required because by default rebase wants a single revision. This still isn't a perfect workflow, since it needs the user to name the first commit of each desired branch (not the tip - aesthetically superior in my opinion, but this is a quibble).

The syntax is not awful although dedicated porcelain would be really slick, and if it were discoverable how to do this from parallelize then that would also be an acceptable alternative I think.

[martinvonz]

You may already know this, but just to explain the current behavior, jj parallelize --help says this:

The command effectively says "these revisions are actually independent",
meaning that they should no longer be ancestors/descendants of each other.

The current behavior is consistent with that description.

I think your proposal is also reasonable. I know we've talked about it before (maybe in #1079 but I haven't verified). Maybe we could allow jj parallelize --group yk..t --group x..l to say that internal dependencies within each group should be preserved but dependencies between them should not. I haven't thought much about how well that would work. There might be corner cases.