FR: `jj linearize`

jj parallelize (https://docs.jj-vcs.dev/latest/cli-reference/#jj-parallelize):

Parallelize revisions by making them siblings 但是有时我希望实际使修订版"线性";即,给它们一个父子关系。 (例如,在只有我自己工作的仓库中,并直接推送到main时,我可能有许多可以推送的修订版,但当然我想要维护main的线性历史。因此,我需要手动将它们排列成一个链,然后才能推送main。此操作也有助于确保在按某种方式排序修订版时不会出现冲突。) 这可以通过多次调用jj rebase来实现,但并不具备良好的扩展性。看起来jj arrange对在"分支"之间移动修订版并不适用;例如,jj new 'trunk()'; jj new 'trunk()'; jj arrange 'trunk()::'无法让我将它们设置为父子关系。 我不确定这是否是一个好主意,因此欢迎讨论。运行jj rebase并不是什么大问题,而且我并不经常这样做。但是,也许无论如何也很方便有一个类似于jj parallelize的镜像操作? 一些想法:

• 我不知道是否应该是非交互式的。如果我有提交 A、B 和 C 并运行jj linearize A B C(假设是位置性修订版),jj将如何决定顺序?
• 我可以想象一个类似于jj bookmark list --sort的 --order标志,但感觉并不那么有用,因为它只能操作 jj 知道的随机元数据,例如提交者时间戳或其他内容,而用户可能希望实际语义上对修订版进行排序。
• 另一种选择是"修订版将按给定的顺序处理,且每个后续修订版都是前一个的子版本",但这并不真正适用于实际的修订版表达式(jj linearize 'A|B') , 它们本质上是集合,因此无序。拓扑顺序也不是确定的(实现可能是,但通常不能假设)。
• 还有一个选择是,它可以使用 --stdin标志并接受标准输入上的更改 ID 或提交 ID 列表,然后将其用作祖先 -> 后代顺序。然后,用户可以脚本它,例如jj log -G -r 'mutable()' -T 'commit_id ++ "\n"' | jj linearize --stdin或类似(糟糕的示例,因为它没有使用用户定义的顺序,但你明白了)。
• jj arrange 使用的 TUI 很不错,其中所有给定的修订版都被放入一个单一链中(具有某些默认的排序,例如按提交者时间戳),用户可以根据需要重新排序它们。一个文本缓冲区(例如git rebase -i或hg histedit)也可以工作,这对于批量编辑可能更好,因为许多用户在编辑器中具有更多的行编辑功能。也许这也可以作为一个选项?
• 冲突实际上不是一个问题,因为这将遇到与手动jj rebase命令相同的"问题"。
• 这也可以非常简单,不接受其他任何标志