]>
Commit | Line | Data |
---|---|---|
b2d09f06 JL |
1 | From: Linus Torvalds <torvalds () osdl ! org> |
2 | To: git@vger.kernel.org | |
3 | Date: 2005-11-08 1:31:34 | |
4 | Subject: Real-life kernel debugging scenario | |
5 | Abstract: Short-n-sweet, Linus tells us how to leverage `git-bisect` to perform | |
6 | bug isolation on a repository where "good" and "bad" revisions are known | |
7 | in order to identify a suspect commit. | |
8 | ||
9 | ||
10 | How To Use git-bisect To Isolate a Bogus Commit | |
11 | =============================================== | |
12 | ||
13 | The way to use "git bisect" couldn't be easier. | |
14 | ||
15 | Figure out what the oldest bad state you know about is (that's usually the | |
16 | head of "master", since that's what you just tried to boot and failed at). | |
17 | Also, figure out the most recent known-good commit (usually the _previous_ | |
18 | kernel you ran: and if you've only done a single "pull" in between, it | |
19 | will be ORIG_HEAD). | |
20 | ||
21 | Then do | |
22 | ||
23 | git bisect start | |
24 | git bisect bad master <- mark "master" as the bad state | |
25 | git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or | |
26 | whatever other known-good | |
89438677 | 27 | thing you booted last) |
b2d09f06 JL |
28 | |
29 | and at this point "git bisect" will churn for a while, and tell you what | |
30 | the mid-point between those two commits are, and check that state out as | |
addf88e4 | 31 | the head of the new "bisect" branch. |
b2d09f06 JL |
32 | |
33 | Compile and reboot. | |
34 | ||
35 | If it's good, just do | |
36 | ||
37 | git bisect good <- mark current head as good | |
38 | ||
39 | otherwise, reboot into a good kernel instead, and do (surprise surprise, | |
40 | git really is very intuitive): | |
41 | ||
42 | git bisect bad <- mark current head as bad | |
43 | ||
44 | and whatever you do, git will select a new half-way point. Do this for a | |
45 | while, until git tells you exactly which commit was the first bad commit. | |
46 | That's your culprit. | |
47 | ||
48 | It really works wonderfully well, except for the case where there was | |
49 | _another_ commit that broke something in between, like introduced some | |
50 | stupid compile error. In that case you should not mark that commit good or | |
51 | bad: you should try to find another commit close-by, and do a "git reset | |
52 | --hard <newcommit>" to try out _that_ commit instead, and then test that | |
53 | instead (and mark it good or bad). | |
54 | ||
55 | You can do "git bisect visualize" while you do all this to see what's | |
56 | going on by starting up gitk on the bisection range. | |
57 | ||
58 | Finally, once you've figured out exactly which commit was bad, you can | |
59 | then go back to the master branch, and try reverting just that commit: | |
60 | ||
61 | git checkout master | |
62 | git revert <bad-commit-id> | |
63 | ||
64 | to verify that the top-of-kernel works with that single commit reverted. | |
65 |