git-log:具有拓扑排序的合并提交的祖先分支的输出顺序。

Question

我的项目中有一段代码依赖于此命令的输出：

git log -n 2 --topo-order --pretty=format:"%H"

这被应用于主分支上的合并提交(合并的拉请求)，并假设结果是当前(合并)提交和来自特性分支的父提交的散列。所以就这样吧。

master   a - b - m
          \     /
feature    x - y 

在合并提交m上执行时，假设结果是m y而不是m b。我通过检查多个这样的合并提交来验证，确实是这样的--始终返回特性分支的父级。但是，在git-log --topo-order的文档中，我发现没有保证首先打印哪个父分支。

谁能解释在使用git-log --topo-order时如何选择首先打印哪个父分支，以及为什么它总是在我的用例中首先显示特性分支？

Answer 1

内部git log算法是将“新”(未访问)提交插入优先级队列。整个循环是：

while queue is not empty:
    commit = queue.remove_front()
    ... deal with commit ...

其中，deal with代码可以将提交的父程序插入队列中。

--topo-order开关简单地(或者实际上是复杂的)修改提交的优先级，Git沿着合并的两条腿前进，这样您就可以从一条腿得到所有东西，然后从另一条腿得到所有东西。

作为joanis notes in a comment，文档显式地使父排序不指定。这使得Git实现能够在将来切换到一个新的算法，这可能会选择另一个“起点腿”。所以，依靠你现在得到的信息是不明智的。

(我认为您现在得到的是，父提交是按照提交日期顺序排序的，因此如果父提交#1的提交器时间戳比父提交日期2更早，git log --topo-order将首先跟踪leg-2。但是这段代码非常混乱，有很多黑暗的角落，所以我不愿意说这是真的。)

如果您知道在某个变量$H中有一个合并提交哈希ID，或者找到了一个名为$name的合并提交哈希ID，那么获得这个哈希ID和父哈希ID的一个完全可靠的方法就是使用git rev-parse来完成它：

git rev-parse ${H} ${H}^2

或者：

git rev-parse ${name} ${name}^2

请注意，如果您有一个任意表达式$expr，git rev-parse可以将其转换为散列ID，那么在添加^2后缀以获取第二个父级之前，最好先这样做一次。这是因为有些表达式会“消耗”后缀。例如，gitrevisions语法:/fix nasty bug是在提交消息中搜索文本的有效方法。添加^2生成:/fix nasty bug^2，它搜索bug^2，而不是先找到哈希，然后转移到第二个父节点。所以：

H=$(git rev-parse ${expr}) || exit
H2=$(git rev-parse ${H}^2)

是一种可靠的方式，可以用shell脚本编写命令，将表达式转换为所需的两个散列ID。