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

Or if you are looking for the commit that fixed a bug, you might use

------------------------------------------------
git bisect start --term-new fixed --term-old broken
------------------------------------------------

Then, use `git bisect <term-old>` and `git bisect <term-new>` instead
of `git bisect good` and `git bisect bad` to mark commits.

Bisect visualize/view
~~~~~~~~~~~~~~~~~~~~~

To see the currently remaining suspects in 'gitk', issue the following
command during the bisection process (the subcommand `view` can be used
as an alternative to `visualize`):

------------
$ git bisect visualize
------------

Git detects a graphical environment through various environment variables:
`DISPLAY`, which is set in X Window System environments on Unix systems.
`SESSIONNAME`, which is set under Cygwin in interactive desktop sessions.
`MSYSTEM`, which is set under Msys2 and Git for Windows.
`SECURITYSESSIONID`, which may be set on macOS in interactive desktop sessions.

If none of these environment variables is set, 'git log' is used instead.
You can also give command-line options such as `-p` and `--stat`.

------------
$ git bisect visualize --stat
------------

Bisect log and bisect replay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After having marked revisions as good or bad, issue the following
command to show what has been done so far:

------------
$ git bisect log
------------

If you discover that you made a mistake in specifying the status of a
revision, you can save the output of this command to a file, edit it to
remove the incorrect entries, and then issue the following commands to
return to a corrected state:

------------
$ git bisect reset
$ git bisect replay that-file
------------

Avoiding testing a commit
~~~~~~~~~~~~~~~~~~~~~~~~~

If, in the middle of a bisect session, you know that the suggested
revision is not a good one to test (e.g. it fails to build and you
know that the failure does not have anything to do with the bug you
are chasing), you can manually select a nearby commit and test that
one instead.

For example:

------------
$ git bisect good/bad			# previous round was good or bad.
Bisecting: 337 revisions left to test after this (roughly 9 steps)
$ git bisect visualize			# oops, that is uninteresting.
$ git reset --hard HEAD~3		# try 3 revisions before what
					# was suggested
------------

Then compile and test the chosen revision, and afterwards mark
the revision as good or bad in the usual manner.

Bisect skip
~~~~~~~~~~~

Instead of choosing a nearby commit by yourself, you can ask Git to do
it for you by issuing the command:

------------
$ git bisect skip                 # Current version cannot be tested
------------

However, if you skip a commit adjacent to the one you are looking for,
Git will be unable to tell exactly which of those commits was the
first bad one.

You can also skip a range of commits, instead of just one commit,
using range notation. For example:

------------