Implement jj parallelize

[emesterhazy]

This is an implementation of the simple version of jj parallelize from FR #1079.

---

Parallelize revisions by making them siblings

Running jj parallelize 1::2 will transform the history like this:

3
|             3
2            / \
|    ->     1   2
1            \ /
|             0
0

Each of the target revisions is rebased onto the parents of the root(s) of
the target revset (not to be confused with the repo root). The children of
the head(s) of the target revset are rebased onto the target revisions.

The target revset is the union of the REVISIONS arguments.

The target revset being parallelized must satisfy several conditions,
otherwise the command will fail.

1. The heads of the target revset must not have different children.
2. The roots of the target revset must not have different parents.
3. The parents of all target revisions except the roots must also be
   parallelized. This means that the target revisions must be connected.

[emesterhazy]

I still need to add a change log entry for this, but I'd like to get some feedback first. This also depends a commit from the diffbase that exposes a rebase_descendants function from cli/commands/rebase.rs that is also used for jj split --siblings.

[emesterhazy]

@yuja This draft was broken by #3407 since I was using the RevsetExpression returned by parse_union_revsets to get the heads and roots of the user provided revset along with evaluate_revset. RevsetExpressionEvaluator doesn't appear to expose a way to get the heads and roots of a revset.

I'm not very familiar with these APIs and haven't dug into the details yet to figure out how to fix this. If you have a suggestion please let me know.

[emesterhazy]

@yuya I got this working again by making WorkspaceCommandHelper::attach_revset_evaluator a public function, but I'm not sure if this is what you'd recommend. Let me know what you think.

[martinvonz]

@yuya I got this working again by making WorkspaceCommandHelper::attach_revset_evaluator a public function, but I'm not sure if this is what you'd recommend. Let me know what you think.

We also have callers at Google that use evaluate_revset() with a revset they build up programmatically with some parts coming from parsed user expressions (and they do more than intersection, so RevsetExpressionEvaluator::intersect_with() is not enough). So we will also want evaluate_revset() to be restore or for attach_revset_evaluator() to become public.

[yuja]

@yuya I got this working again by making WorkspaceCommandHelper::attach_revset_evaluator a public function,

For #3410, I suggested making attach_revset_evaluator() public. I don't think the function name is nice, but it would be useful because callers are likely to do .evaluate_to_commits()/_commit_ids() instead of evaluate()....

[emesterhazy]

I think this is in pretty good shape now and ready for another review.

[yuja]

lgtm, but I don't have much expertise.

[PhilipMetzger]

Minor things, as I'm not a expert.

[emesterhazy]

Ok I have combed this over and I think I resolved all of the correctness problems. I also adjusted the rules about which revsets can be parallelized. The full description is in the commit description / --help output, but here are the rules:

• The heads of the target revset must not have different children.
• The roots of the target revset must not have different parents.
• The parents of all target revisions except the roots must also be parallelized. This means that the target revisions must be connected.

There are a bunch of comments on this PR, some of which are stale. Happy to open a new PR if would make it easier to review the current version.

[martinvonz]

Thanks!

[emesterhazy]

Ok I addressed the latest round of comments. I'll leave this open for a few days in case anyone else has thoughts. We can always make changes later as well.

[martinvonz]

Ok I addressed the latest round of comments. I'll leave this open for a few days in case anyone else has thoughts. We can always make changes later as well.

Thanks! I don't think you need to leave it open. It's been open for several days already and I haven't heard any objections. As you say, we can adjust things later if necessary. So feel free to merge as far as I'm concerned.

[emesterhazy]

Ok sounds good. I forgot to push (actually I accidentally pushed a new branch with -c), so the latest version is up now.

I also added one more test case and tweaked the documentation. I'll merge this soon.

[PhilipMetzger]

LG