FR: split: CLI 标志,用于跟随描述

你的功能请求是否与一个问题有关？请描述。 此功能建立在以下基础之上： * #10195 * #10196 两种常见的工作流程导致用户在对某个提交执行 jj split 操作时，该提交已做出某些更改，已有描述说明这些更改，并且已有对这些更改的书签： 1. 用户将前提条件的重构移入父提交。 使用堆叠差异工作流程，这通常会导致两个独立的审查单元（例如 PR），其中 原始审查单元仍然保留在子提交中。 在更典型的 GitHub 多提交 PR 工作流程中，这通常会导致一个 PR，其中包含两个提交，且分支跟踪子提交。 2. 用户将后续工作移入子提交。 无论是使用堆叠差异工作流程还是使用多提交 PR 的工作流程，这通常会导致两个独立的审查单元，其中 原始审查单元仍然保留在父提交中 并为子提交分配了新的审查单元。 在以上两种情况下，可以通过确定原始提交的逻辑后继来确定最终提交，该提交具有与原始提交相同的描述。要求用户在使用 CLI 标志之前识别后继或在使用交互式提示之后识别后继是不必要的。jj split 命令应允许用户选择仅按照描述进行操作。 Google 版 Mercurial 中的 jj split 命令提供了此跟随描述策略，该策略会回退到交互式提示。对于该策略的功能请求是 Google 内部最受欢迎的 jj 功能之一。 ### 描述你希望的解决方案 此请求的目标是为用户提供更多可用于别名的选项，以便自定义分割操作的工作流程。 跟随描述： 添加新的标志值 --identity=follow-description，以根据描述选择后继提交。如果原始提交具有非空描述，且新的提交中恰好有一个具有匹配描述的提交，则该提交将成为后继。 （请参见下面的回退情况。） 多个身份策略： 接受 --identity 标志的多个值，以允许用户定义在 follow-description 无法选择后继时的回退行为。示例： --identity=follow-description,interactive。 默认回退策略： 当使用 --identity=follow-description 且没有唯一的、非空的匹配提交时，jj split 将选择后继，就像没有使用 --identity 标志一样。 关于回退与错误的注意事项： interactive 策略在 Ui.can_prompt() 返回 false 时将继续出错。这种明显的不一致是有意的： jj split --identity=follow-description 的行为完全可从其输入中预测，并且可以合理地用于脚本。但是，如果 Ui.can_prompt() 返回 false，则任何发送到 jj split 的输入文本将永远不会被读取，并且将…