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

[Stephan Beyer <s-beyer@gmx.net>]

On 11/11/2017 03:34 PM, Junio C Hamano wrote:
> 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