FR: split: CLI flag to follow description

Is your feature request related to a problem? Please describe.

This builds upon:

• #10195
• #10196

Two common workflows lead to users running jj split on a commit that makes some change, already has a description describing that change, and already has a bookmark on the change:

1. The user is moving prerequisite refactoring into a parent commit. With a stacked diff workflow, this would typically lead to two separate review units (such as PRs) with the original review unit remaining with the child commit. In a more typical GitHub multi-commit PR workflow, this would typically lead to a PR with both commits with the branch tracking the child commit.
2. The user is moving follow-up work into a child commit. In both a stacked diff workflow and a workflow where multi-commit PRs are used, this would typically lead to two separate review units with the original review unit remaining with the parent commit and a new review unit assigned to the child commit.

In both of these cases, the logical successor to the original commit can be identified as the resulting commit with the same description as the original commit. Requiring the user to identify the successor before the split using a CLI flag or after the split using an interactive prompt is unnecessary. The split command should allow the user to choose to simply follow the description.

The split command in Google’s fork of Mercurial provided this follow-description heuristic that fell back to an interactive prompt. The feature request for that heuristic is one of the most-requested jj features internally at Google.

Describe the solution you'd like

The goal of this request is to give users more options that can be used in aliases to customize the behavior of split for their workflows.

Follow description: Add a new flag value --identity=follow-description that chooses the successor commit based on the description. If the original commit has a non-empty description, and exactly one of the new commits has a matching description, then that commit becomes the successor. (See below for the fallback case.)

Multiple identity strategies: Accept multiple values for the --identity flag to allow users to define fallback behavior when follow-description cannot select a successor. Example: --identity=follow-description,interactive.

Default fallback strategy: When --identity=follow-description is used and there is no unique, non-empty, matching commit, then jj split will choose a successor as if --identity was omitted.

Note on fallback vs error: The interactive strategy will continue to error when Ui.can_prompt() returns false. This apparent inconsistency is deliberate: The behavior of jj split --identity=follow-description is entirely predictable from its inputs and may reasonably be used by scripts. However, if Ui.can_prompt() returns false, then any text sent to jj split as input to the interactive successor prompt will never be read and would be an error in a script.

Change IDs in description editor: As with --identity=interactive, the original commit’s change ID will be shown for both commits.

Commit trailers: There will be no special handling for commit trailers. A difference in trailers will be considered a difference in the descriptions, and a description containing only trailers will be considered non-empty.

Non-interactive split with no --message flag: jj split {file} with no --message flag gives the original description to the commit with {file} and leaves the remaining commit's description blank. If users configure follow-description as the first identity strategy, then the change ID and bookmarks would go to the commit with the selected changes. There will be no special handling for this case. This may be unexpected for some users, but is technically consistent with the policy of following the description.

Describe alternatives you've considered

New flag: A new flag could be used to enable the follow-description strategy, but as with the interactive strategy, this creates potentially-conflicting flag combinations. Using a single value with multiple possible values (including repeated values) is simpler to implement and simpler for users to understand.

Commit trailers: The follow-description strategy could have special handling for commit trailers.

• A commit containing only trailers could be considered empty. I could find no precedence for this in the jj source, so a commit containing only trailers will be considered non-empty and will be eligible for description matching. (cf. commit.rs:197-201, split.rs:310-317)
• Two commit descriptions differing only in trailers could be considered matching. I could find no precedence for this in the jj source, so I will use simple string equality to determine if two commit descriptions match. (cf. upload.rs:612)

Additional context

Prerequisite FR:

• #10195
• #10196

Other past discussions about jj split's choice of successor:

• #3419
• #6458
• #6466

Edit: Fixed typo:

-and exactly one of the new commits has a matching commit
+and exactly one of the new commits has a matching description