On Sat, 11 Nov 2017, Kevin Daudt wrote:
> 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.
ok, anyone else have any strong opinions on the subject?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
