Re: Article about "git bisect run" on LWN
From: Christian Couder <hidden>
Date: 2016-06-15 22:46:07
Le vendredi 6 février 2009, Christian Couder a écrit :
Le jeudi 5 février 2009, Ingo Molnar a écrit :quoted
- Feature: better "git bisect next" support.You probably mean "git bisect skip" here.quoted
Sometimes a commit wont build. In that case we have "git bisect next", but last i checked that only jumps a single commit - and build breakages often have a large scope - full trees that got merged upstream, etc. Most of the time those build breakages are uninteresting and the build-broken window does not contain the bad commit. So it would be nice to have a "git bisect next --left=20%" type of feature. This would jump 20% commits to the "left" from the bisection point, towards the 'known bad' set of commits, but still within the bisection window. Similarly, "git bisect next --right=20%" would jump towards the known-good edge of the bisection window (but still within the bisection window).In the following thread, H. Peter Anvin suggested an algorithm to deal with this kind of problem: http://thread.gmane.org/gmane.comp.version-control.git/98164/ And I suggested a simpler one, that might be implemented without having to port "git bisect skip" code to C first, but I did not work on it yet.quoted
Currently when i hit a build error during auto-bisection, it aborts and i have to intervene manually. But with a bigger jump distance i could use git-bisect-next reliably in scripts too. Likewise, users too hit build breakages often, and find it hard to get out of the window of breakage. With the high-order tree structure of the kernel repository that is rather non-intuitive to do as well, and often people make mistakes and test the wrong commit.I am working slowly on "git replace" these days and, if everything goes well, it should make it possible to use "replace" refs when bisecting, so that people could bisect on commit trees where many breakages have been removed. And as refs can be shared, this means that users and developers should be able to easily share these improved trees. Another way to work around breakages could be to have a list of commits and ranges of commits that should always be skipped and always pass them to "git bisect skip" before using "git bisect run". Something like that perhaps: $ git bisect start <bad> <good> $ git bisect skip $(cat always_skipped.txt) $ git bisect run ./my_test_script.sh
It might be useful to have a list of always good commits too, and use it like this: $ git bisect start <bad> <good> $(cat always_good.txt) $ git bisect skip $(cat always_skipped.txt) $ git bisect run ./my_test_script.sh or you may want to use grafts in your bisection repository. See the following thread about bisection breakage in the btrfs history: http://thread.gmane.org/gmane.comp.version-control.git/105186/ Regards, Christian.