Re: "git bisect" takes exactly one bad commit and one or more good?

From: Stephan Beyer <s-beyer@gmx.net>
Date: Nov 12, 2017, 21:13 UTC
Message-ID: <4cc5519b-f384-f9e7-3261-f36e1943a776@gmx.net>
In-Reply-To: <xmqq8tfcevev.fsf@gitster.mtv.corp.google.com>

On 11/11/2017 03:34 PM, Junio C Hamano wrote:

Show 12 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
> 
>>> "You use it by first telling it a "bad" commit that is known to
>>> contain the bug, and a "good" commit that is known to be before the
>>> bug was introduced."
>>
>> Yeah, 'and at least a "good" commit' would be better.
> 
> Make it "at least one" instead, perhaps?
> 
> I somehow thought that you technically could force bisection with 0
> good commit, even though no sane person would do so.

Thanks for pointing that out but I disagree with the part after "even though" :)

Imagine you add a test case that was totally uncovered before and now reveals a bug. You want to find the introduction of the bug, so you can either check out the first commit you think where that bug did not exist, then you find out that its also a bad commit, so you check out another commit... essentially you are manually doing a "bisect" but less efficient. So it would be better to let "git bisect" do its job without knowing a good commit in advance. Sounds perfectly sane to me.

The probably insane thing is that there are currently performance issues with git bisect. So you *are* probably faster by guessing. But that is what my patch series [1] was about (and that I postponed in favor of other conflicting work on bisect).

1. https://public-inbox.org/git/1460294354-7031-1-git-send-email-s-beyer@gmx.net/

Cheers Stephan