revisions left to test after this (roughly 9 steps)
------------------------------------------------

Keep repeating the process: compile the tree, test it, and depending
on whether it is good or bad run `git bisect good` or `git bisect bad`
to ask for the next commit that needs testing.

Eventually there will be no more revisions left to inspect, and the
command will print out a description of the first bad commit. The
reference `refs/bisect/bad` will be left pointing at that commit.


Bisect reset
~~~~~~~~~~~~

After a bisect session, to clean up the bisection state and return to
the original HEAD, issue the following command:

------------------------------------------------
$ git bisect reset
------------------------------------------------

By default, this will return your tree to the commit that was checked
out before `git bisect start`.  (A new `git bisect start` will also do
that, as it cleans up the old bisection state.)

With an optional argument, you can return to a different commit
instead:

------------------------------------------------
$ git bisect reset <commit>
------------------------------------------------

For example, `git bisect reset bisect/bad` will check out the first
bad revision, while `git bisect reset HEAD` will leave you on the
current bisection commit and avoid switching commits at all.


Alternate terms
~~~~~~~~~~~~~~~

Sometimes you are not looking for the commit that introduced a
breakage, but rather for a commit that caused a change between some
other "old" state and "new" state. For example, you might be looking
for the commit that introduced a particular fix. Or you might be
looking for the first commit in which the source-code filenames were
finally all converted to your company's naming standard. Or whatever.

In such cases it can be very confusing to use the terms "good" and
"bad" to refer to "the state before the change" and "the state after
the change". So instead, you can use the terms "old" and "new",
respectively, in place of "good" and "bad". (But note that you cannot
mix "good" and "bad" with "old" and "new" in a single session.)

In this more general usage, you provide `git bisect` with a "new"
commit that has some property and an "old" commit that doesn't have that
property. Each time `git bisect` checks out a commit, you test if that
commit has the property. If it does, mark the commit as "new";
otherwise, mark it as "old". When the bisection is done, `git bisect`
will report which commit introduced the property.

To use "old" and "new" instead of "good" and bad, you must run `git
bisect start` without commits as argument and then run the following
commands to add the commits:

------------------------------------------------
git bisect old [<rev>]
------------------------------------------------

to indicate that a commit was before the sought change, or

------------------------------------------------
git bisect new [<rev>...]
------------------------------------------------

to indicate that it was after.

To get a reminder of the currently used terms, use

------------------------------------------------
git bisect terms
------------------------------------------------

You can get just the old term with `git bisect terms --term-old`
or `git bisect terms --term-good`; `git bisect terms --term-new`
and `git bisect terms --term-bad` can be used to learn how to call
the commits more recent than the sought change.

If you would like to use your own terms instead of "bad"/"good" or
"new"/"old", you can choose any names you like (except existing bisect
subcommands like `reset`, `start`, ...) by starting the
bisection using

------------------------------------------------
git bisect start --term-old <term-old> --term-new <term-new>
------------------------------------------------

For example, if you are looking for a commit that introduced a
performance regression, you might use

------------------------------------------------
git bisect start --term-old fast --term-new slow