Bisect
A test passed at tag v1.0 and fails on the newest commit, 1024 commits later. Testing them one at a time means 1024 runs; there is a way to name the culprit in ten.
- ▸One test in the middle of the range clears half the suspects. Do it again. And again.
- ▸This search rewrites nothing: your branch never moves while git hunts the commit that broke the build.
- ▸Hand the whole hunt to a script, and exit code 0 means good, not failure.
The test test_login is green at tag v1.0. It is red on the newest commit. Somewhere in the 1024 commits between the two, one change broke it. Which one?
The obvious method: check out each commit, run the test, and see when red first appears. Start just after v1.0, walk forward, and the first commit whose test fails is the one that broke it. It works. It is also slow: put the break at commit 896 of 1024 and you run the test 896 times before you reach it. Worst case is 1024 runs for 1024 commits. The cost grows in lockstep with the range.
In the panel, drop the break on the first commit or on any eighth of the range, then walk the range from v1.0, one test run per commit. The counter tracks how many test runs it took to reach it. Push the break toward the far end and the count climbs with it. A range twice as long costs twice as many runs. That linear price is the thing worth beating.