Fix up the bisect guide to be more user-friendly

For some reason starting a bisect with `git bisect start <bad> <good>`
quietly accepts invalid revisions, whereas doing it this way will cause
git to complain so the user knows they've made a mistake.

Signed-off-by: Jeremy Cline <jcline@redhat.com>
This commit is contained in:
Jeremy Cline 2018-06-18 14:18:57 -04:00
parent 8960f4c2c4
commit 0be84787b0
No known key found for this signature in database
GPG key ID: 9223308FA9B246DB

View file

@ -78,7 +78,13 @@ between major versions (e.g. `v4.16` and `v4.15`) new configuration options
will be added and removed as you bisect. It's _usually_ safe to select the will be added and removed as you bisect. It's _usually_ safe to select the
default.] default.]
. Start a new `git-bisect` with `git bisect start <bad> <good>`. . Start a new `git-bisect` with `git bisect start`.
. Mark the newest version that works as "good" with `git bisect good <tag>`.
For example: `git bisect good v4.16.8`.
. Mark the first version that does not work as "bad" with `git bisect bad
<tag>`. For example: `git bisect bad v4.17`.
. <<build-custom-kernel.adoc#building-the-kernel,Build the kernel>>. Sometimes . <<build-custom-kernel.adoc#building-the-kernel,Build the kernel>>. Sometimes
commits cannot be built. If this happens, skip the commit with `git bisect commits cannot be built. If this happens, skip the commit with `git bisect
@ -91,7 +97,5 @@ skip`.
. If the new kernel works, mark it as good with `git bisect good`. Otherwise, . If the new kernel works, mark it as good with `git bisect good`. Otherwise,
mark it as bad with `git bisect bad`. mark it as bad with `git bisect bad`.
. Check out the next commit to test by running `git bisect next`.
. Repeat the previous five steps until you've found the commit that introduced . Repeat the previous five steps until you've found the commit that introduced
the problem. the problem.