Le vendredi 6 février 2009, Christian Couder a écrit : > Le jeudi 5 février 2009, Ingo Molnar a écrit : > > > - Feature: better "git bisect next" support. > > You probably mean "git bisect skip" here. > > > 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. > > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
