More git bisect modes

More git bisect modes

[John Tapsell]

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.
* 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).
* 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.


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

John

Re: More git bisect modes

[Nanako Shiraishi]

Quoting John Tapsell <johnflux@gmail.com>:

> * An exponential back-off.  Typically I know that HEAD is broken, and
> I don't know when it used to work.

I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: More git bisect modes

[John Tapsell]

2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
> Quoting John Tapsell <johnflux@gmail.com>:
>
>> * An exponential back-off.  Typically I know that HEAD is broken, and
>> I don't know when it used to work.
>
> I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?

I believe this makes it start from the very first commit.  This
probably much further back than most people would actually want to
start from.
(Also there seems to be a bug here, in that  'git bisect run' requires
you to have both a good and a bad commit.  Also the man page doesn't
document this)

John Tapsell

Re: More git bisect modes

[Junio C Hamano]

John Tapsell <johnflux@gmail.com> writes:

> 2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
>> Quoting John Tapsell <johnflux@gmail.com>:
>>
>>> * An exponential back-off.  Typically I know that HEAD is broken, and
>>> I don't know when it used to work.
>>
>> I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?
>
> I believe this makes it start from the very first commit.  This
> probably much further back than most people would actually want to
> start from.
> (Also there seems to be a bug here, in that  'git bisect run' requires
> you to have both a good and a bad commit.  Also the man page doesn't
> document this)

Hmm, interesting.  I am sure we will soon hear from Christian, but
personally I never felt the need for "run" to work without any bad one, as
the first few rounds would almost always end up to be a debugging session
of the run script for me, as in:

	... oh, somebody broke this somewhere ...
	... write a validate script ...
	$ edit runme ; chmod +x runme
        $ ./runme
        ... yeah, it is broken and runme script detects breakage
        $ git checkout HEAD~200
        $ ./runme
        ... ok, it used to work here and runme exits Ok
        $ git bisect good
        $ git bisect bad @{-1}
        $ ./runme
        ... ok, runme script appears to be ok
        $ git bisect run ./runme

bisect run, was Re: More git bisect modes

[Johannes Schindelin]

Hi,

On Thu, 5 Mar 2009, Junio C Hamano wrote:

> [...] personally I never felt the need for "run" to work without any bad 
> one, as the first few rounds would almost always end up to be a 
> debugging session of the run script for me, as in:
> 
> 	... oh, somebody broke this somewhere ...
> 	... write a validate script ...
> 	$ edit runme ; chmod +x runme
>         $ ./runme
>         ... yeah, it is broken and runme script detects breakage
>         $ git checkout HEAD~200
>         $ ./runme
>         ... ok, it used to work here and runme exits Ok
>         $ git bisect good
>         $ git bisect bad @{-1}
>         $ ./runme
>         ... ok, runme script appears to be ok
>         $ git bisect run ./runme

That reminds me of a personal gripe with "bisect run": You cannot use it 
like this:

	$ git bisect run 'make test'

as it interprets 'make test' as a name of an executable.  That makes 
'bisect run' rather less useful to me.

Ciao,
Dscho

Re: bisect run, was Re: More git bisect modes

[John Tapsell]

2009/3/5 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>
>> [...] personally I never felt the need for "run" to work without any bad
>> one, as the first few rounds would almost always end up to be a
>> debugging session of the run script for me, as in:
>>
>>       ... oh, somebody broke this somewhere ...
>>       ... write a validate script ...
>>       $ edit runme ; chmod +x runme
>>         $ ./runme
>>         ... yeah, it is broken and runme script detects breakage
>>         $ git checkout HEAD~200
>>         $ ./runme
>>         ... ok, it used to work here and runme exits Ok
>>         $ git bisect good
>>         $ git bisect bad @{-1}
>>         $ ./runme
>>         ... ok, runme script appears to be ok
>>         $ git bisect run ./runme
>
> That reminds me of a personal gripe with "bisect run": You cannot use it
> like this:
>
>        $ git bisect run 'make test'
>
> as it interprets 'make test' as a name of an executable.  That makes
> 'bisect run' rather less useful to me.

A very quick test seems to show that:

$ git bisect run make test

Works as you want.  Maybe a quick example of this could be added to
the man page.

>
> Ciao,
> Dscho
>
>

Re: bisect run, was Re: More git bisect modes

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 591 bytes --]

Hi,

On Thu, 5 Mar 2009, John Tapsell wrote:

> 2009/3/5 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > That reminds me of a personal gripe with "bisect run": You cannot use it
> > like this:
> >
> >        $ git bisect run 'make test'
> >
> > as it interprets 'make test' as a name of an executable.  That makes
> > 'bisect run' rather less useful to me.
> 
> A very quick test seems to show that:
> 
> $ git bisect run make test
> 
> Works as you want.  Maybe a quick example of this could be added to
> the man page.

Indeed, the source code agrees with you.

Thanks,
Dscho

Re: More git bisect modes

[Christian Couder]

Le jeudi 5 mars 2009, John Tapsell a écrit :
> 2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
> > Quoting John Tapsell <johnflux@gmail.com>:
> >> * An exponential back-off.  Typically I know that HEAD is broken, and
> >> I don't know when it used to work.
> >
> > I thought 'git bisect' already worked with only bad commit(s) without
> > any good commit for a long time?
>
> I believe this makes it start from the very first commit.  This
> probably much further back than most people would actually want to
> start from.
> (Also there seems to be a bug here, in that  'git bisect run' requires
> you to have both a good and a bad commit.  Also the man page doesn't
> document this)

Yeah you are right. Do you want to try to fix this bug ?

Thanks in advance,
Christian.

Re: More git bisect modes

[Christian Couder]

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.