Re: [PATCH] bisect: clarify that one can select multiple good commits

[Kevin Daudt <me@ikke.info>]

On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:
> 
> Current man page for "bisect" is inconsistent explaining the fact that
> "git bisect" takes precisely one bad commit, but one or more good
> commits, so tweak the man page in a few places to make that clear.
> 
> rday
> 
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
> 
> ---
> 
>   i also exercised literary license to reword an example to look for a
> commit where performance was *degraded* rather than improved, since i
> think that's the sort of thing that people would be more interested
> in.
> 
>  In fact, `git bisect` can be used to find the commit that changed
>  *any* property of your project; e.g., the commit that fixed a bug, or
> -the commit that caused a benchmark's performance to improve. To
> +the commit that caused a benchmark's performance to degrade. To
>  support this more general usage, the terms "old" and "new" can be used
>  in place of "good" and "bad", or you can choose your own terms. See
>  section "Alternate terms" below for more information.
> @@ -58,7 +58,7 @@ $ git bisect bad                 # Current version is bad
>  $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good
>  ------------------------------------------------
> 

I think this example was meant to suggest that it's not only possible to
find bad things (bugs, performance degradations), but also the opposite
(when was a bug fixed, what caused the performance to change). 

So I think it's good to keep the example like it is.