2026/9/12 16:06:18
FEATURED · 精选文章 
Jujutsu 的 -r、-s、-f、-o、-A、-B、-t 这些选版参数该怎么选【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj在 Jujutsujj中执行jj log、jj rebase、jj diff、jj restore、jj squash时会反复遇到-r、-s、-f、-o、-A、-B、-t这些短选项。它们的作用是统一的但新手很难记住哪个命令该用哪个。本文依据仓库内 CLI options for specifying revisions给出每个参数的语义、典型命令以及如何验证执行结果让你在操作前就能判断该用哪个参数。先分清两类参数源与目标官方指南 把选版参数分成两组一组指定操作的源一组指定操作的目标插入位置或内容落点。指定源长选项短选项含义--revision或--revisions-r默认选择方式尤其适用于不需要指定目标位置的命令--source-s指定的 revision 及其所有后代--from-f某个 revision 的内容contents或该 revision 上的 bookmarks--branch-b相对于目标位置的一整个分支需要源和目标两者时长选项短选项含义--onto-o在指定 revision 下创建子 revision--insert-after-A插入在指定 revision 与其子 revision之间--insert-before-B插入在指定 revision 与其父 revision之间--to、--into-t把所选内容放入哪个 revision、把 bookmark 移到哪里、或把from的内容与哪个 revision 比较判断的第一步就靠这张表你的命令是在移动 revision还是在搬运文件内容前者用-r/-s加-o/-A/-B后者用-f加-t或--into。-r 还是 -s是否要连带后代一起操作大多数命令接受-r语义是选中 revset 里列出的 revision不多也不少。例如jj log -r REV只显示REV这些 revisionREV替换为你的 revision ID 或 bookmark 名下同。jj split -r REV只把REV拆成多个 revision。-s用于那些同时操作 revision 及其后代的命令-s REV本质上等价于-r REV::。文档给出的例子是jj fix -s xyzfix 工具必须作用于xyz及其全部后代所以该命令只接受-s而不接受-r以此传达会连后代一起处理这一事实。jj rebase是典型场景。教程 中把 B2 直接 rebase 到 A 上$ jj rebase -s puqltutt -o nuvyytnq # Replace the IDs by what you have for B2 and A Rebased 2 commits to destination Working copy () now at: qzvqqupx 1978b534 (conflict) C上面是文档示例其中puqltutt、nuvyytnq是教程仓库中的 change ID你需要替换为自己仓库中 B2 和 A 的 ID。jj rebase使用-s所以 B2 的后代 C 也一起被移动输出中的 Rebased 2 commits to destination 即文档展示的示例结果。如果只想移动单个 revision 而不带后代改用-rjj rebase -r REV -o main-f 和 -t操作文件内容而不是 revision 位置当你想比较、恢复、合并内容文件状态而非移动 revision 时用--from-f和--to/--into-tjj diff --from F --to T # 比较 F 与 T 两个 revision 的文件 jj restore --from F --to T # 把 F 的文件内容复制到 T jj squash --from F --into T # 把 F 的文件改动移到 T两个注意点来自文档原文接受--into的命令也接受--to。拿不准时用--to总不会错。--into之所以单独存在是因为它在英语中读起来更自然例如jj squash --from X --into Y。有些操作内容的命令也接受-r此时含义是与其父 revision 比较。例如jj diff -r R表示比较 revisionR与其父 revisionR-。FAQ 中把改错位置的改动挪到另一个 commit的场景就是这样用-f/-t的先jj new建一个子 commit再把原 commit 的内容恢复到工作副本不指定-t时默认目标是工作副本$ jj restore --from 31a347e0 Working copy () now at: pvnrkl 468104c featureB Parent commit (-) : lnvvtr/1 b8004ea (divergent) featureA31a347e0为 FAQ 文档示例中的 commit ID替换为你要恢复内容的 revision。-o、-A、-Brevision 插入到哪移动 revision 的命令还需要说明放到哪里三个参数的区别--onto REV-o REV把 revision 作为REV的子 revision。--insert-after REV-A REV作为REV的子 revision同时是REVREV的原有子 revision的父 revision。--insert-before REV-B REV作为REV-REV的原有父 revision的子 revision同时是REV的父 revision。文档给出的对照例子jj rebase -r REV -o main # REV 变为 main 的子 revision jj rebase -r REV -B yyy # REV 被插到 yyy 与其父 revision 之间 jj rebase -r REV -A main -B yyy # REV 被插到 main 与 yyy 之间 jj revert -r xyz -o main # 创建一个撤销 xyz 的 revision并 rebase 到 main 之上当你要在链中间插入一个新 commit而不是移动已有 commit 时jj new也接受-A/-B。FAQ 的示例文档示例替换为对应 commit 后执行# 在 xxxxxxxx 之后插入一个新 commit $ jj new --no-edit -A xxxxxxxx -m Another feature Working copy () now at: uuuuuuuu 1c3cff09 (empty) Another feature Parent commit (-) : xxxxxxxx ef612875 Add new feature # 在 yyyyyyyy 与 vvvvvvvv 之间插入一个新 commit $ jj new --no-edit -A yyyyyyyy -B vvvvvvvv -m Yet another feature Working copy () now at: tttttttt 938ab831 (empty) Yet another feature Parent commit (-) : yyyyyyyy b624cf12 Existing work执行后可用jj log核对新 commit 的父子关系是否与预期一致输出中 Parent commit (-) 一行就是插入位置是否正确的直接证据。执行后如何验证结果文档中出现的验证手段主要有三种可按任务类型选用看 rebase/插入的回显。如上例Rebased 2 commits to destination、Working copy () now at: ...和Parent commit (-): ...会直接打印执行后的位置均为文档示例输出具体 ID 因仓库而异。用jj log查看结构。rebase 或插入后跑jj log确认 revision 的父子关系变成了预期形状教程 在 rebase 产生冲突后就是靠jj log观察新结构的。用jj diff判等。FAQ 在挪动改动后用两条 diff 验证内容等价$ jj diff --from b80 --to - # No output means these are identical $ jj diff --from 31a --to # No output means these are identical文档说明这两条命令无输出即表示两个 revision 内容相同。这是-f/-t参数最典型的验证用法jj diff --from 旧 --to 新无输出就是成功。几个容易混淆的特殊情形省略-r多数命令用选项传 revision、用位置参数传路径如jj diff -r REV file.txt。但有些命令本身不接受路径因此允许省略-r直接把 revision 当位置参数例如jj new xyz等价于jj new -r xyz。允许省略-r的命令是jj abandon、jj describe、jj duplicate、jj metaedit、jj new、jj parallelize、jj show。-c不是通用的-r。jj git push --change REV-c REV表示创建一个新生成名字的 bookmark 并立即推送jj restore --changes-in REV-c REV表示删除REV中对指定文件的改动。后者刻意不用-r是因为jj restore -r REV容易被误读为把文件从REV恢复。-b是整条分支。jj rebase --branch REV-b REV按拓扑分支相对某个基点整体 rebase以下命令等价jj rebase -o main -b jj rebase -o main -r (main..):: jj rebase -o main -s roots(main..) jj rebase -o main最后一条说明-b 是 rebase 未指定源时的默认值——把当前分支整条挂到 main 上是极常见的操作。遇到本文没覆盖的命令时CLI reference 是自动生成的实验性参考可能与jj help输出不完全一致官方建议以jj help COMMAND的输出为准。也就是说记住上面的分组规则源用-r/-s/-f/-b目标用-o/-A/-B/-t具体命令是否接受某个参数用jj help现查现用。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Jujutsu 的 -r、-s、-f、-o、-A、-B、-t 这些选版参数该怎么选？
Jujutsu 的 -r、-s、-f、-o、-A、-B、-t 这些选版参数该怎么选【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj在 Jujutsujj中执行jj log、jj rebase、jj diff、jj restore、jj squash时会反复遇到-r、-s、-f、-o、-A、-B、-t这些短选项。它们的作用是统一的但新手很难记住哪个命令该用哪个。本文依据仓库内 CLI options for specifying revisions给出每个参数的语义、典型命令以及如何验证执行结果让你在操作前就能判断该用哪个参数。先分清两类参数源与目标官方指南 把选版参数分成两组一组指定操作的源一组指定操作的目标插入位置或内容落点。指定源长选项短选项含义--revision或--revisions-r默认选择方式尤其适用于不需要指定目标位置的命令--source-s指定的 revision 及其所有后代--from-f某个 revision 的内容contents或该 revision 上的 bookmarks--branch-b相对于目标位置的一整个分支需要源和目标两者时长选项短选项含义--onto-o在指定 revision 下创建子 revision--insert-after-A插入在指定 revision 与其子 revision之间--insert-before-B插入在指定 revision 与其父 revision之间--to、--into-t把所选内容放入哪个 revision、把 bookmark 移到哪里、或把from的内容与哪个 revision 比较判断的第一步就靠这张表你的命令是在移动 revision还是在搬运文件内容前者用-r/-s加-o/-A/-B后者用-f加-t或--into。-r 还是 -s是否要连带后代一起操作大多数命令接受-r语义是选中 revset 里列出的 revision不多也不少。例如jj log -r REV只显示REV这些 revisionREV替换为你的 revision ID 或 bookmark 名下同。jj split -r REV只把REV拆成多个 revision。-s用于那些同时操作 revision 及其后代的命令-s REV本质上等价于-r REV::。文档给出的例子是jj fix -s xyzfix 工具必须作用于xyz及其全部后代所以该命令只接受-s而不接受-r以此传达会连后代一起处理这一事实。jj rebase是典型场景。教程 中把 B2 直接 rebase 到 A 上$ jj rebase -s puqltutt -o nuvyytnq # Replace the IDs by what you have for B2 and A Rebased 2 commits to destination Working copy () now at: qzvqqupx 1978b534 (conflict) C上面是文档示例其中puqltutt、nuvyytnq是教程仓库中的 change ID你需要替换为自己仓库中 B2 和 A 的 ID。jj rebase使用-s所以 B2 的后代 C 也一起被移动输出中的 Rebased 2 commits to destination 即文档展示的示例结果。如果只想移动单个 revision 而不带后代改用-rjj rebase -r REV -o main-f 和 -t操作文件内容而不是 revision 位置当你想比较、恢复、合并内容文件状态而非移动 revision 时用--from-f和--to/--into-tjj diff --from F --to T # 比较 F 与 T 两个 revision 的文件 jj restore --from F --to T # 把 F 的文件内容复制到 T jj squash --from F --into T # 把 F 的文件改动移到 T两个注意点来自文档原文接受--into的命令也接受--to。拿不准时用--to总不会错。--into之所以单独存在是因为它在英语中读起来更自然例如jj squash --from X --into Y。有些操作内容的命令也接受-r此时含义是与其父 revision 比较。例如jj diff -r R表示比较 revisionR与其父 revisionR-。FAQ 中把改错位置的改动挪到另一个 commit的场景就是这样用-f/-t的先jj new建一个子 commit再把原 commit 的内容恢复到工作副本不指定-t时默认目标是工作副本$ jj restore --from 31a347e0 Working copy () now at: pvnrkl 468104c featureB Parent commit (-) : lnvvtr/1 b8004ea (divergent) featureA31a347e0为 FAQ 文档示例中的 commit ID替换为你要恢复内容的 revision。-o、-A、-Brevision 插入到哪移动 revision 的命令还需要说明放到哪里三个参数的区别--onto REV-o REV把 revision 作为REV的子 revision。--insert-after REV-A REV作为REV的子 revision同时是REVREV的原有子 revision的父 revision。--insert-before REV-B REV作为REV-REV的原有父 revision的子 revision同时是REV的父 revision。文档给出的对照例子jj rebase -r REV -o main # REV 变为 main 的子 revision jj rebase -r REV -B yyy # REV 被插到 yyy 与其父 revision 之间 jj rebase -r REV -A main -B yyy # REV 被插到 main 与 yyy 之间 jj revert -r xyz -o main # 创建一个撤销 xyz 的 revision并 rebase 到 main 之上当你要在链中间插入一个新 commit而不是移动已有 commit 时jj new也接受-A/-B。FAQ 的示例文档示例替换为对应 commit 后执行# 在 xxxxxxxx 之后插入一个新 commit $ jj new --no-edit -A xxxxxxxx -m Another feature Working copy () now at: uuuuuuuu 1c3cff09 (empty) Another feature Parent commit (-) : xxxxxxxx ef612875 Add new feature # 在 yyyyyyyy 与 vvvvvvvv 之间插入一个新 commit $ jj new --no-edit -A yyyyyyyy -B vvvvvvvv -m Yet another feature Working copy () now at: tttttttt 938ab831 (empty) Yet another feature Parent commit (-) : yyyyyyyy b624cf12 Existing work执行后可用jj log核对新 commit 的父子关系是否与预期一致输出中 Parent commit (-) 一行就是插入位置是否正确的直接证据。执行后如何验证结果文档中出现的验证手段主要有三种可按任务类型选用看 rebase/插入的回显。如上例Rebased 2 commits to destination、Working copy () now at: ...和Parent commit (-): ...会直接打印执行后的位置均为文档示例输出具体 ID 因仓库而异。用jj log查看结构。rebase 或插入后跑jj log确认 revision 的父子关系变成了预期形状教程 在 rebase 产生冲突后就是靠jj log观察新结构的。用jj diff判等。FAQ 在挪动改动后用两条 diff 验证内容等价$ jj diff --from b80 --to - # No output means these are identical $ jj diff --from 31a --to # No output means these are identical文档说明这两条命令无输出即表示两个 revision 内容相同。这是-f/-t参数最典型的验证用法jj diff --from 旧 --to 新无输出就是成功。几个容易混淆的特殊情形省略-r多数命令用选项传 revision、用位置参数传路径如jj diff -r REV file.txt。但有些命令本身不接受路径因此允许省略-r直接把 revision 当位置参数例如jj new xyz等价于jj new -r xyz。允许省略-r的命令是jj abandon、jj describe、jj duplicate、jj metaedit、jj new、jj parallelize、jj show。-c不是通用的-r。jj git push --change REV-c REV表示创建一个新生成名字的 bookmark 并立即推送jj restore --changes-in REV-c REV表示删除REV中对指定文件的改动。后者刻意不用-r是因为jj restore -r REV容易被误读为把文件从REV恢复。-b是整条分支。jj rebase --branch REV-b REV按拓扑分支相对某个基点整体 rebase以下命令等价jj rebase -o main -b jj rebase -o main -r (main..):: jj rebase -o main -s roots(main..) jj rebase -o main最后一条说明-b 是 rebase 未指定源时的默认值——把当前分支整条挂到 main 上是极常见的操作。遇到本文没覆盖的命令时CLI reference 是自动生成的实验性参考可能与jj help输出不完全一致官方建议以jj help COMMAND的输出为准。也就是说记住上面的分组规则源用-r/-s/-f/-b目标用-o/-A/-B/-t具体命令是否接受某个参数用jj help现查现用。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
)
