Thread (13 messages) flat view 13 messages, 6 authors, 2016-06-15

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help