“--abort”和“--quit”作为“cherry-pick”的定序器子命令有什么不同？

Question

根据doc，在 的三个音序器子命令中cherry-pick，我们有这两个，对我来说，奇怪地相似：

--quit

忘记当前正在进行的操作。可用于在樱桃挑选或恢复失败后清除音序器状态。

--abort

取消操作并返回前序状态。

---

到目前为止，我一直在使用--abort，而且效果很好。什么--quit是不同/优选的用例？

Answer 1

如果您还记得这git rebase是一系列git cherry-pick操作，^再加上开始和结束处的一些有用的技巧，那就更有意义了。

\n

假设您有以下一系列提交：

\n

...--o--*--...--o   <-- mainline\n         \\\n          A--B--C   <-- feature\n

\n

您想要了解feature最新情况，mainline以便：

\n

git checkout feature\ngit rebase mainline\n

\n

Git 首先枚举可从feature( C, B, A, *, ...) 可达的提交以及可从mainline(unnamed, ..., *, ...) 可达的提交。mainline它从feature集合²中减去该集合并使用反向拓扑顺序，以便它现在具有哈希 ID A、B、 和 ，并在 Git 称为定序器的C事物中列出。（定序器还记录操作，在本例中是 rebase /cherry-pick。定序器还用于多个恢复。定序器可以中途停止，然后使用 恢复。这就是为什么它需要知道操作：我们是继续挑选、恢复还是变基？）--continue

\n

然后，GitHEAD在顶部的提交处分离mainline并通过定序器运行操作（无论它是什么）。由于操作是“rebase”，因此定序器的每一步都是一个简单的单提交樱桃选择：

\n

(with)\n\n...--o--*--...--o   <-- mainline, HEAD\n         \\\n          A--B--C   <-- feature\n\n(execute git cherry-pick A to produce)\n\n                  A'   <-- HEAD\n                 /\n...--o--*--...--o   <-- mainline\n         \\\n          A--B--C   <-- feature\n

\n

这可能会因合并​​冲突而失败。如果是这样，定序器将停止，从而在索引和工作树中留下一堆合并冲突。A'您可以修复它们并恢复定序器（如果需要，如果您没有自己制作，它将承诺您制作A'），或者选择两种停止之一，“中止”或“退出”。如果你恢复\xe2\x80\x94或者如果事情进展顺利\xe2\x80\x94我们继续（尝试）cherry-pick B：

\n

                  A'-B'   <-- HEAD\n                 /\n...--o--*--...--o   <-- mainline\n         \\\n          A--B--C   <-- feature\n

\n

假设这也成功了，我们继续尝试挑选，C但这次尝试失败了。排序器停止，在索引和工作树中留下一团糟，与我们上面看到的相同图表：存在但A'不存在。B'C'

\n

假设我们决定停下来：目前完成挑选C太难了，我们需要退后一步做点别的事情。您现在有两个选择：中止或退出。

\n

如果您选择--abort，Git 会将您的重新附加HEAD到feature，给出：

\n

...--o--*--...--o   <-- mainline\n         \\\n          A--B--C   <-- feature (HEAD)\n

\n

A'和在哪里B'？B' 好吧，如果您知道自己在做什么，则可以将它们从引用日志中捞出来，或者在选择之前已经巧妙地附加了分支或标签名称--abort。但如果你选择--quit，Git 会终止 rebase而不移动HEAD，这样你最终会得到：

\n

                  A'-B'   <-- HEAD\n                 /\n...--o--*--...--o   <-- mainline\n         \\\n          A--B--C   <-- feature\n

\n

但现在可以给自己一个干净的索引和工作树git reset --hard。（或者，您可以将混乱留在原地。）因此，您不必足够聪明，在--quit.

\n

这基本上就是全部内容了。:-) 但是经过漫长而令人沮丧的 rebase后之后，您想要保存到目前为止所取得的成果并返回到非 rebase 工作，然后再返回 rebase ，即“退出”变体不知何故感觉更满足。

\n

（我认为这里真正缺少的是保存序列器状态的其余部分并稍后恢复它的选项。但是，序列器状态是每个工作树的，因此如果您有一个正在进行的变基任务并且必须用更高的值来中断它优先级任务，您可以为更高优先级的任务添加工作树。通过 Git 2.15 添加的工作树中的各种错误并不那么令人鼓舞，但它们现在似乎表现良好。还添加了工作树覆盖另一个更大的缺失部分，即保存正在进行的冲突合并并在以后恢复它的能力。）

\n\n

¹但请注意，旧式非交互式git-rebase--am仍然使用git format-patch和git am。在某些情况下，此过程对于重命名的文件效果不佳，并且无法复制“不进行更改”提交，但运行速度更快。在大多数情况下，尽管底层机制发生了变化，这种风格和cherry-pick风格都应该给出相同的结果，特别是因为cherry-pick变体默认不复制“不进行任何更改”提交。

\n

²变基还会减去集合中存在mainline且与集合中的任何提交相同的git patch-id任何提交feature任何提交，当然，默认情况下，它会减去所有合并。

\n

Answer 2

--abort会带您回到开始挑选操作之前的位置，而--quit会退出操作并使您保持当前所在的修订版本。我想不出除了您在遇到无法自动挑选的修订版后想要继续不同的方向之外的用例，这就是为什么挑选首先停止的原因，对吧？