Stochastic bisection in Git
Stochastic bisection in Git
Posted Dec 14, 2021 19:43 UTC (Tue) by NYKevin (subscriber, #129325)In reply to: Stochastic bisection in Git by mathstuf
Parent article: Stochastic bisection in Git
> Future work to say "crap, I gave some bad information" and rewind a few steps would help quite a bit.
git bisect log and git bisect replay already do exactly that.
> Another one is "please carry around this patch to anywhere that is jumped to because it needs fixed in order to test my problem, but is not the problem I'm trying to figure out right now". Sometimes you can just leave the diff in the working tree, but I'd rather `git bisect` know what it is for and give me a conflict resolution flow instead of just refusing to jump to the next candidate commit.
You can build it yourself out of git bisect run, although built-in functionality would be Nice To Have. But if you've already turned the test into a single command, writing a wrapper script that applies/reverts a fixed patch is not *that* much extra work.
Posted Dec 14, 2021 20:50 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Oh nifty. I knew of `log`, but had missed `replay`. However, I feel that `git bisect undo [n]` would also be useful (at least to avoid touching files all over the place in the process of restarting since I suspect that the replay is not done purely in-index quite yet[1]).
> You can build it yourself out of git bisect run, although built-in functionality would be Nice To Have. But if you've already turned the test into a single command, writing a wrapper script that applies/reverts a fixed patch is not *that* much extra work.
Sure, but that's generally a "hindsight is 20/20" situation. The problem is usually that such things are discovered in the process of bisecting, so by the time I have a robust reproducer script to give to `git bisect run`, I've already done a bisection…
[1] Willing to be pleasantly surprised though :) .
Posted Dec 14, 2021 21:24 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link]
#!/bin/bash
patch -p2 /path/to/file.diff # Replace 2 with the correct number.
You would still need to handle the "what if patch(1) fails?" case, though.
Posted Dec 23, 2021 17:54 UTC (Thu)
by zblaxell (subscriber, #26385)
[Link]
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?
Stochastic bisection in Git
Stochastic bisection in Git
git show -s --oneline
echo "Press ^D when finished testing this commit."
bash
echo -n "Was this commit (G)ood, (B)ad, or (S)kip? "
read REPLY
git reset --hard HEAD
case "$REPLY" in
g|good) exit 0;;
b|bad) exit 1;;
s|skip) exit 125;;
*) echo "Unrecognized input, aborting."; exit -1;;
esac
Stochastic bisection in Git