| |||||||||||||
|
| |||||||||||||
Fully automated bisecting with "git bisect run"Fully automated bisecting with "git bisect run"Posted Feb 5, 2009 2:13 UTC (Thu) by ncm (subscriber, #165)Parent article: Fully automated bisecting with "git bisect run"
Perhaps I am showing my ignorance here, but doesn't this require that buggy intermediate versions of the code be scrubbed out of the repository, so that the bisection may choose any random intermediate version? Or must known-toxic versions labeled to deflect bisect from choosing them?
(Log in to post comments)
Fully automated bisecting with "git bisect run" Posted Feb 5, 2009 3:48 UTC (Thu) by dtlin (✭ supporter ✭, #36537) [Link]
The article did mention that exit code 125 signaled "skip this commit" -- if you have your git run script return that for known-toxic versions, that would do the trick. Or so it seems, from reading the article; I've never tried it myself.
Fully automated bisecting with "git bisect run" Posted Feb 5, 2009 5:58 UTC (Thu) by christian_couder (subscriber, #56350) [Link]
Yes this is the idea.
Exit code 125 tells "git bisect" to use "git bisect skip". "git bisect skip" marks the current commit as untestable and checks out another one nearby to be tested.
See the "git bisect" documentation for more information:
http://www.kernel.org/pub/software/scm/git/docs/git-bisec...
Fully automated bisecting with "git bisect run" Posted Feb 5, 2009 7:44 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
note that to cause problems the buggy intermediate versions need to be buggy in a way that your test script can't tell from the failure you are looking for.
how big a problem this is depends on what your failure condition is.
if you know that when it fails it generates message X then you just look for message X and mark everything else as 'good' (it may actually crash and not do anything useful, but it's not the bug you are looking for)
if you are looking for a hang (or failure to boot like Ingo did in one example) then it's harder, you may end up going down the wrong path becouse some other bug is causing the problem (failing to boot in this example)
Bisect on patchset boundaries ? Posted Feb 6, 2009 10:33 UTC (Fri) by lbt (subscriber, #29672) [Link]
The "buggy intermediate versions" problem is one that I would have expected more attention to be drawn to. I've done a few bisects and had my filesystem fail to mount on several cuts during one run.
A bisect that throws you into the middle of a patch set that messes with your filesystem is a dangerous place to be; especially when you ask 'normal' users to run a bisect on their everyday machines without warning them that they are potentially about to expose their data to random collections of code.
The problem is that all patches are supposed to be non-toxic - and git is deliberately not good at revisionist history ;)
That means that marking 'safe' bisect points is hard - but maybe a step in the right direction would be worth cutting on patchset boundaries?
Or maybe an external (well, inside .git/) list of 'good' commits eg rc releases?
Obviously this would make the bisect slightly less efficient but it may reduce the risk.
|
|
||||||||||||