On 11/11/2017 03:34 PM, Junio C Hamano wrote:
> Christian Couder 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
On Sat, 2017-11-11 at 10:27 -0500, Robert P. J. Day wrote:
>
> 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
On Sat, 11 Nov 2017, Junio C Hamano wrote:
> Christian Couder 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
On Sat, 11 Nov 2017, Junio C Hamano wrote:
> Christian Couder 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
Christian Couder 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"
On Sat, Nov 11, 2017 at 12:22 PM, Robert P. J. Day
wrote:
>
> more on "git bisect" ... the man page seems to make it clear that
> bisection takes *precisely* one "bad" commit, and one *or more* good
> commits, is that correct?
Yeah, that's true.
> seems that way, given
6 matches
Mail list logo