Stochastic bisection in Git

'git bisect edit-log', maybe? Something similar to 'git rebase --edit-todo', so we don't all have to write the same shell script that chops off the last line between 'git bisect log' and 'git bisect replay'.

Speaking of rebase, that would be an awesome workflow for git bisect. Check out the commit to be tested, then cherry-pick a list of patches, with quick options to skip or take over manually (or leverage the git-rebase machinery). When a test result is received, rebase the list of patches to the next commit to be tested. Keep the rebase branch heads around in the log, so that later bisects over the same range don't need to have rerere done to them over and over.

I currently do this by having a script check out the revision chosen by bisect in a separate working tree, cherry-pick a stack of patches (and ignore patches that are known to fail if and only if they're not needed), then build and test that instead of what bisect has checked out. Sometimes I need to have different patches on different revision ranges but it doesn't happen often enough to bother automating it.

That's all assuming I don't give up on git bisect completely, and just take a flat list of commits and run the bisection algorithm myself. After implementing the editable log, the cherry-picking, and adding other conveniences like a place to store annotations about test results (admittedly this is most useful for recording statistical data to compute confidence in the results), getting a list of revisions to test and running a search algorithm against them is not that much extra work...and then what's left for git bisect to do?