问题描述
使用git bisect时，可以运行git bisect skip来将当前提交标记为不可构建/不可测试，以尝试让Git选择其他提交进行测试.
When using git bisect, one can run git bisect skip to mark the current commit as being an unbuildable / untestable one, to try and get Git to pick some other commit to test instead.
Git如何决定在git bisect skip之后尝试执行哪个提交?实验表明，这不仅是相邻的提交，而且我无法弄清楚模式.
How does Git decide which commit to try after a git bisect skip? Experimenting shows it's not just an adjacent commit, but I can't work out the pattern.
编辑:我知道基本的git bisect是二进制搜索，但是我对git bisect skip很好奇，它显然在做一些更复杂的事情.
Edit: I'm aware the basic git bisect is a binary search, but I'm curious about git bisect skip, which is clearly doing something more complicated.
实验表明，这不仅仅是选择相邻的提交；下面将创建100个编号为0到99的提交，然后将它们二等分.第一个提交git bisect处于中间位置，但此后每个git bisect skip似乎都是随机选择的.
Experimentation shows it's not just picking an adjacent commit; the below creates 100 commits numbered 0–99 then starts bisecting them. The first commit git bisect picks is in the middle, but each git bisect skip thereafter seems to be more-or-less randomly selected.
$ git init
Initialized empty Git repository in .git/
$ for (( i=0; i<100; i++ )); do echo $i > file; git add file; git commit -m $i >/dev/null; done # Create some dummy commits
$ git bisect start HEAD $(git rev-list --max-parents=0 HEAD) # HEAD is bad, root commit is good.
Bisecting: 49 revisions left to test after this (roughly 6 steps)
[099e5cf2ccde625f92dc369da6cad0bdf2852ce4] 49
$ git bisect skip
Bisecting: 49 revisions left to test after this (roughly 6 steps)
[88c8208a7c4322222124167e49f07c741af7d3d8] 60
$ git bisect skip
Bisecting: 49 revisions left to test after this (roughly 6 steps)
[04695f2e5b2473c3ac72435c0dbfc3ba1375abda] 88
$ git bisect skip
Bisecting: 49 revisions left to test after this (roughly 6 steps)
[1e9bf3d29589bcac2d8c467245ae8d446c195252] 40
$ git bisect skip
Bisecting: 49 revisions left to test after this (roughly 6 steps)
[9459ed79e4112d674681c8f0f921127217c7ebc6] 13
推荐答案
我深入研究了Git源代码，并发现了大部分答案……
I did some digging into the Git source code and found most of an answer myself...
从Git v1.6.4开始(具体来说，从提交ebc9529f 起)使用带有偏倚的PRNG(伪随机数生成器)"来确定跳过提交后要尝试的提交.
As of Git v1.6.4 (specifically, as of commit ebc9529f), Git uses "a PRNG (pseudo random number generator) with a bias" to determine which commit to try next after skipping one.
我不能说我遵循算法本身(自v2.8.1起，它从首次添加以来就基本上没有受到影响)，但是commit消息在解释发生的事情方面做得很合理:
I can't say I follow the algorithm itself (which, as of v2.8.1, appears to be fundamentally untouched since it was first added), but the commit message does a reasonable job of explaining what's going on:
使用带有偏差的PRNG(伪随机数生成器)应该更好 而不是在3个固定比率之间交替.
Using a PRNG (pseudo random number generator) with a bias should be better than alternating between 3 fixed ratios.
在具有许多无法测试的提交的存储库中，应防止交替 在许多提交不可测试的区域之间.偏见应该有利于 可以提供更多信息的提交，因此二等分过程 不应失去太多效率.
In repositories with many untestable commits it should prevent alternating between areas where many commits are untestable. The bias should favor commits that can give more information, so that the bisection process should not loose much efficiency.
HPA建议使用PRNG，并发现最好的偏向是提高 PRNG给出的0到1与1.5的幂之比.
HPA suggested to use a PRNG and found that the best bias is to raise a ratio between 0 and 1 given by the PRNG to the power 1.5.
因此，看起来好像Git选择了下一个提交以进行随机尝试，但是选择了随机分布来(希望)选择为二进制搜索提供更多信息的提交，并避免可能在不可测试的提交区域中的提交
So it looks as though Git picks the next commit to try at random, but the random distribution was picked to (hopefully) choose commits that give more information for the binary search and to avoid commits likely to be in regions of untestable commits.
这篇关于git bisect如何跳过选择下一个提交尝试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！