Re: More git bisect modes

[Christian Couder <chriscool@tuxfamily.org>]

Le jeudi 5 mars 2009, John Tapsell a écrit :
> Hi,
>
>   Although "git bisect" is called, well, bisect, it would be nice to
> have other modes.
>
> * A completely linear version - check every version.  Particularly
> useful after rebasing to make sure all the commits still compile.

I will answer this one bellow along with the exponential back-off.

> * An allow-for-mistakes-bisect.  This would use a bisection technique
> that would allow for a minimum of 1 mistake when marking a commit good
> or bad.  This point isn't particularly to help those with fat fingers,
> but for bugs that are subtle and for bugs that are caused by multiple
> commits.  (I can go into the details of how to do such a bisect
> later).

Yeah, Ingo Molnar also asked for something like this. But I think it is 
quite complex. I hope it will be easier after the improvements I am 
currently working on. I hope to send something early next week.

> * An exponential back-off.  Typically I know that HEAD is broken, and
> I don't know when it used to work.  It would be nice to exponentially
> go back through the commits to find the first working commit, then
> bisect from there.

I think your first idea above and this one could be implemented in a new 
command called for example "git check".

It could be used it like this:

$ git check COMMAND $(git rev-list HEAD~10..)

that would check out each of the 10 last revisions and run COMMAND on each 
one after check out, and at the end it could report about the exit code of 
command for each of these revisions.

It could be used also with tags like that:

$ git check COMMAND $(git tag | tail -10)

After that a --bisect flag could be implemented. That would automatically 
call "git bisect" to bisect if the exit code changed from "bad" to "good" 
at one point.

Then if one adds a --expo flag to "git rev-list" that could be used for the 
exponential back off you want.

>   Before I start working on the code for any of these, do people like
> this?  Would this fit into the 'git bisect' command?

I think it would be usefull, but I don't think the first and last one would 
fit well into the "git bisect" command.

Best regards,
Christian.