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@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. > > 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.
