`git rebase`使用哪个命令从合并分支中挑选提交？

Question

假设我们有:

C1--C2--C3--C6--C7   <- topic, HEAD
 \   \     /
  \  C4--C5      
   \
    C8--C9           <- master

(我们添加了一个空file1并提交C1,添加一个空file2并提交C2,等等).

然后我们做:

$ git rebase master

结果是:

C1--C8--C9                         <- master
         \
         C4'--C2'--C5'--C3'--C7'   <- topic, HEAD

我已经在这里创建了一个自动bash脚本,你可以根据需要进行测试.

正如我在git-scm.com一书中的第3.6章中所学到的,Git跳过了C6哪个是合并结果,所以C6'这里没有介绍.

我的问题是,Git使用哪个命令从topic分支中挑选？为什么结果...-C4'--C2'--C5'--C3'--C7'不是...-C2'--C3'--C4'--C5'--C7'(按时间顺序)？

Answer 1

（顺便说一下，感谢重现脚本\xe2\x80\x94，它在这里非常有帮助。）

\n\n

过去的顺序有所不同，但通常它是通过运行生成的git rev-list（默认情况下，它的姊妹命令git log仅生成哈希 ID）。由于哈希 ID 对人类来说很难，因此通常更容易使用git log来查看顺序。

\n\n

在本例中，订单来自：

\n\n

$ git log --oneline --reverse --no-merges master..topic\n5ff52aa C4\naefbb19 C2\n0363c27 C5\n90aaf5d C3\nf953082 (topic) C7\n

\n\n

然而，如果我们添加--topo-order，这git rebase在各种旧的 Git 版本中都是如此，我们会得到：

\n\n

$ git log --oneline --reverse --topo-order --no-merges master..topic\naefbb19 C2\n90aaf5d C3\n5ff52aa C4\n0363c27 C5\nf953082 (topic) C7\n

\n\n

在有多个活动提交可供选择的情况下，实际顺序基于提交时间戳。也就是说，Git 正在进行修订行走，从提示提交向后进行。每当发生合并时，Git 都会将所有父级放入优先级队列中，从而增加要访问的提交数量。优先级队列的默认排序顺序基于提交者时间戳。由于git rebase没有设置任何其他优先级，因此使用的是这一优先级。

\n\n

（new-ish、非拓扑排序的顺序是 new-ishgit rebase--helper内部命令的结果，该命令首次出现在 Git 版本 2.13 中。合并实际上“保留”\xe2\x80\x94，重新创建\xe2\x80 \x94variantgit rebase -p仍然使用拓扑排序。花哨的新标签git rebase -r不需要拓扑排序。）

\n