From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 05 Mar 2009 10:31:22 GMT
Subject: Re: More git bisect modes
Message-ID: <7vvdqo1csl.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <43d8ce650903050217m2885692dkcef08ab2a5f60082@mail.gmail.com>

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