Re: Article about "git bisect run" on LWN

[Christian Couder <chriscool@tuxfamily.org>]

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.