Re: [PATCH] bisect: clarify that one can select multiple good commits
- From
Kevin Daudt <me@ikke.info>
- Date
- Nov 11, 2017, 13:44 UTC
- Message-ID
- <20171111134430.GA30635@alpha.vpn.ikke.info>
- In-Reply-To
- <alpine.LFD.2.21.1711110820370.8941@localhost.localdomain>
On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:
Show 27 quoted lines
> > 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.