Re: [PATCH] bisect: clarify that one can select multiple good commits
- Date: Sat, 11 Nov 2017 14:44:30 +0100
- From: Kevin Daudt <me@xxxxxxxxx>
- Subject: Re: [PATCH] bisect: clarify that one can select multiple good commits
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.
> Signed-off-by: Robert P. J. Day <rpjday@xxxxxxxxxxxxxx>
> 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 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.