Git 什么'；“--abort”和“--quit”作为“cherry pick”的sequencer子命令有什么不同？

根据，在

cherry pick

的三个sequencer子命令中，我们有两个，对我来说，奇怪地相似：

--quit

忘记当前正在进行的操作。可用于在樱桃拾取或还原失败后清除sequencer状态

取消操作并返回到预排序状态

---

---

到目前为止，我一直使用

--abort

，而且效果很好。如果

--quit

不同/更可取，那么会出现什么样的用例？

--abort

会将您带回到您开始cherry pick操作之前的位置，而

--quit

会退出操作，并保持您当前的版本。我想不出一个用例，除了你在遇到一个无法自动cherry-pick的修订版后想要改变方向，这就是cherry-pick首先停止的原因，对吗？

如果你记得

git-rebase

是一系列

git-cherry-pick

操作，1加上开头和结尾的几个有用的噱头，它更有意义

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

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

Git首先枚举可从

功能访问的提交（
C
，
B
，
A
，
*
，…）以及可从
主线访问的提交（未命名，
*
，…）。它从
功能
集合2中减去
主线
集合，并使用相反的拓扑顺序，这样它现在就有了hash id
A
、
B
、和
C
，列在Git调用sequencer的东西中。（定序器还记录操作，在本例中为重定基/重定基。定序器还用于多次还原。定序器可以中途停止，然后使用
--continue
继续。这就是为什么它需要知道操作：我们是继续重定基、重定基还是重定基？）

Git然后在
mainline
顶端的提交处分离
HEAD
，并通过sequencer运行op，不管它是什么。由于op是“rebase”，sequencer的每个步骤都是一个简单的选择：

(with)

...--o--*--...--o   <-- mainline, HEAD
         \
          A--B--C   <-- feature

(execute git cherry-pick A to produce)

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

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

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

如果选择
--abort
，Git会将
头部重新连接到
功能
，给出：

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

而是一个干净的索引和工作树。因此，您不必非常聪明地在退出之前附加分支名称

这基本上就是它的全部内容。：-）但是在经历了一段长时间的、令人沮丧的、充满冲突的重定基础之后，如果你想保存到目前为止所取得的成果，并在稍后再次回到重定基础之前回到非重定基础的工作中，那么“退出”变体不知何故会感到更满意

（我认为这里真正缺少的是保存sequencer状态的剩余部分并在以后恢复它的选项。然而，sequencer状态是每个工作树的，因此如果您有一个正在进行的重新基址任务，并且必须用一个更高优先级的任务中断它，您可以只为更高优先级的任务添加一个工作树。添加的work-t中的各种错误通过Git 2.15实现的REE并不是那么令人自信，但它们现在确实表现得很好。添加的工作树还掩盖了另一个更大的缺失部分，即保存正在进行的冲突合并并在以后恢复的能力。）


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

2重基还会减去
主线
集合中存在的任何提交，这些提交与
功能
集合中的任何提交具有相同的
git补丁id
，当然，默认情况下，它会减去所有合并。
嗯……我仍然不明白。我必须阅读更多关于整个樱桃拾取过程的详细信息。我想不同之处在于，当有多个提交被选中时。
--abort
将撤消您已经合并的任何提交，而
--quit
将保留这些提交。这一点现在更清楚了。我想我早就将这些过程视为一种事务。要么一直到令人满意的状态，要么永远回滚这是一个有用但有点幼稚的方法，在管道水平上真正发生了什么。也要感谢eftshit0和chepner！
(with)

...--o--*--...--o   <-- mainline, HEAD
         \
          A--B--C   <-- feature

(execute git cherry-pick A to produce)

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

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

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

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