基于极其有限的测试的完全天真的答案:
留待探测的提交范围可以用 来获得git bisect visualize
,这可以粗略地用git bisect visualize | wc -l
或者你有什么来计算。
在进入此状态之前打印的消息似乎大致基于此数量的一半,并取该一半的以 2 为底的对数。
例如,我现在处于一种状态,有人告诉我:
Bisecting: 10 revisions left to test after this (roughly 3 steps)
在这种状态下,我有:
$ git bisect visualize --oneline | wc -l
21
即“10 个修订”实际上意味着在可疑范围内有 21 个提交。我们处于该范围的中间,因此大约有 10 个位于任一方向。为了得到 10,我们计算 21/2,向下取整。为了得到“大约剩下 3 个要测试”,我们只取 10 的基数 2 对数,向下取整。
用我最喜欢的脚本语言(替换你的):
$ txr -P '(let* ((count (length
(get-lines
(open-command "git bisect visualize --oneline"))))
(left (trunc count 2)))
`Bisecting: @left revisions left to test after this \
\ (roughly @(int-flo (log2 left)) steps)`)'
Bisecting: 10 revisions left to test after this (roughly 3 steps)
需要进行一些错误处理,因为bisect
如果您没有报告至少一个好的提交和一个错误的提交,该命令会报错。如果可能发生这种情况,也有一些极端情况,例如避免将 log2 应用为零。