]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-bisect(1) |
2 | ============= | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
215a7ad1 | 6 | git-bisect - Find the change that introduced a bug |
7fc9d69f JH |
7 | |
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
f85a4191 JH |
11 | 'git bisect' start |
12 | 'git bisect' bad <rev> | |
13 | 'git bisect' good <rev> | |
14 | 'git bisect' reset [<branch>] | |
8db9307c | 15 | 'git bisect' visualize |
b595ed14 JH |
16 | 'git bisect' replay <logfile> |
17 | 'git bisect' log | |
7fc9d69f JH |
18 | |
19 | DESCRIPTION | |
20 | ----------- | |
f85a4191 JH |
21 | This command uses 'git-rev-list --bisect' option to help drive |
22 | the binary search process to find which change introduced a bug, | |
23 | given an old "good" commit object name and a later "bad" commit | |
24 | object name. | |
7fc9d69f | 25 | |
f85a4191 | 26 | The way you use it is: |
7fc9d69f | 27 | |
f85a4191 JH |
28 | ------------------------------------------------ |
29 | git bisect start | |
30 | git bisect bad # Current version is bad | |
31 | git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version | |
32 | # tested that was good | |
33 | ------------------------------------------------ | |
7fc9d69f | 34 | |
f85a4191 JH |
35 | When you give at least one bad and one good versions, it will |
36 | bisect the revision tree and say something like: | |
37 | ||
38 | ------------------------------------------------ | |
39 | Bisecting: 675 revisions left to test after this | |
40 | ------------------------------------------------ | |
41 | ||
42 | and check out the state in the middle. Now, compile that kernel, and boot | |
43 | it. Now, let's say that this booted kernel works fine, then just do | |
44 | ||
45 | ------------------------------------------------ | |
46 | git bisect good # this one is good | |
47 | ------------------------------------------------ | |
48 | ||
49 | which will now say | |
50 | ||
51 | ------------------------------------------------ | |
52 | Bisecting: 337 revisions left to test after this | |
53 | ------------------------------------------------ | |
54 | ||
55 | and you continue along, compiling that one, testing it, and depending on | |
56 | whether it is good or bad, you say "git bisect good" or "git bisect bad", | |
57 | and ask for the next bisection. | |
58 | ||
59 | Until you have no more left, and you'll have been left with the first bad | |
60 | kernel rev in "refs/bisect/bad". | |
61 | ||
62 | Oh, and then after you want to reset to the original head, do a | |
63 | ||
64 | ------------------------------------------------ | |
65 | git bisect reset | |
66 | ------------------------------------------------ | |
67 | ||
68 | to get back to the master branch, instead of being in one of the bisection | |
69 | branches ("git bisect start" will do that for you too, actually: it will | |
70 | reset the bisection state, and before it does that it checks that you're | |
71 | not using some old bisection branch). | |
7fc9d69f | 72 | |
8db9307c JH |
73 | During the bisection process, you can say |
74 | ||
75 | git bisect visualize | |
76 | ||
77 | to see the currently remaining suspects in `gitk`. | |
78 | ||
f73ae1fc | 79 | The good/bad input is logged, and `git bisect |
b595ed14 JH |
80 | log` shows what you have done so far. You can truncate its |
81 | output somewhere and save it in a file, and run | |
82 | ||
83 | git bisect replay that-file | |
84 | ||
85 | if you find later you made a mistake telling good/bad about a | |
86 | revision. | |
87 | ||
7fc9d69f JH |
88 | |
89 | Author | |
90 | ------ | |
91 | Written by Linus Torvalds <torvalds@osdl.org> | |
92 | ||
93 | Documentation | |
df8baa42 | 94 | ------------- |
7fc9d69f JH |
95 | Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. |
96 | ||
97 | GIT | |
98 | --- | |
a7154e91 | 99 | Part of the gitlink:git[7] suite |
7fc9d69f | 100 |