On Sat, Nov 11, 2017 at 12:22 PM, Robert P. J. Day <rpj...@crashcourse.ca> 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.