@@ -15,7 +15,7 @@ DESCRIPTION
15
15
The command takes various subcommands, and different options depending
16
16
on the subcommand:
17
17
18
- git bisect start [<paths>...]
18
+ git bisect start [<bad> [<good>...]] [--] [< paths>...]
19
19
git bisect bad <rev>
20
20
git bisect good <rev>
21
21
git bisect reset [<branch>]
@@ -134,15 +134,26 @@ $ git reset --hard HEAD~3 # try 3 revs before what
134
134
Then compile and test the one you chose to try. After that, tell
135
135
bisect what the result was as usual.
136
136
137
- Cutting down bisection by giving path parameter to bisect start
138
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
137
+ Cutting down bisection by giving more parameters to bisect start
138
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
139
139
140
140
You can further cut down the number of trials if you know what part of
141
141
the tree is involved in the problem you are tracking down, by giving
142
142
paths parameters when you say `bisect start`, like this:
143
143
144
144
------------
145
- $ git bisect start arch/i386 include/asm-i386
145
+ $ git bisect start -- arch/i386 include/asm-i386
146
+ ------------
147
+
148
+ If you know beforehand more than one good commits, you can narrow the
149
+ bisect space down without doing the whole tree checkout every time you
150
+ give good commits. You give the bad revision immediately after `start`
151
+ and then you give all the good revisions you have:
152
+
153
+ ------------
154
+ $ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
155
+ # v2.6.20-rc6 is bad
156
+ # v2.6.20-rc4 and v2.6.20-rc1 are good
146
157
------------
147
158
148
159
Bisect run
0 commit comments