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

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Sat, 11 Nov 2017, 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.  For the
> matter, in practice nobody starts with more than one good commit,
> and for that reason, I doubt that the proposed change to overstress
> the fact that you could give two or more "good" ones when starting
> has that much practical value.  The tradeoff of losing the clarity
> coming from giving only the simplest usage pattern for trying to be
> technically more correct that is proposed by this change does not
> sound too good, but it may be just me (who prefers white lies in the
> end-user docs when it buys us more simplicity and clarity). .

  i realize that one of each commit is the simplest use case, but the
scenario that occurred to me is a bunch of branches being merged and,
suddenly, you have a bug, and you're not sure where it came from so
you identify a number of good commits, one per merged branch, and go
from there.

  also, making it clear you can have more than one good commit is
consistent with the synopses, which use ellipses to represent that
very thing.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================