On Sat, Nov 11, 2017 at 12:22 PM, Robert P. J. Day
<rpjday@xxxxxxxxxxxxxx> 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 the ellipses in the
> commands below:
>
> git bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]
> [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]
> git bisect (bad|new|<term-new>) [<rev>]
> git bisect (good|old|<term-old>) [<rev>...]
Yeah indeed.
> however, other parts of the man page seem less clear. just below
> that, a description that bisection takes "a" good commit:
>
> "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.
> and a bit lower, we read "at least one bad ...", which some people
> might interpret as one or more *bad* commits:
>
> "Once you have specified at least one bad and one good commit, git
> bisect selects a commit in the middle of that range of history, checks
> it out, and outputs something similar to the following:"
Yeah, 'Once you have specified one bad and at least one good commit'
would be better.
> if the rules are exactly one bad commit and one or more good, i'll
> submit a patch to reword at least the above, and possibly more if
> necessary.
Sure, thanks,
Christian.
