You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
65 lines
2.4 KiB
65 lines
2.4 KiB
From: Linus Torvalds <torvalds () osdl ! org> |
|
To: git@vger.kernel.org |
|
Date: 2005-11-08 1:31:34 |
|
Subject: Real-life kernel debugging scenario |
|
Abstract: Short-n-sweet, Linus tells us how to leverage `git-bisect` to perform |
|
bug isolation on a repository where "good" and "bad" revisions are known |
|
in order to identify a suspect commit. |
|
|
|
|
|
How To Use git-bisect To Isolate a Bogus Commit |
|
=============================================== |
|
|
|
The way to use "git bisect" couldn't be easier. |
|
|
|
Figure out what the oldest bad state you know about is (that's usually the |
|
head of "master", since that's what you just tried to boot and failed at). |
|
Also, figure out the most recent known-good commit (usually the _previous_ |
|
kernel you ran: and if you've only done a single "pull" in between, it |
|
will be ORIG_HEAD). |
|
|
|
Then do |
|
|
|
git bisect start |
|
git bisect bad master <- mark "master" as the bad state |
|
git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or |
|
whatever other known-good |
|
thing you booted last) |
|
|
|
and at this point "git bisect" will churn for a while, and tell you what |
|
the mid-point between those two commits are, and check that state out as |
|
the head of the new "bisect" branch. |
|
|
|
Compile and reboot. |
|
|
|
If it's good, just do |
|
|
|
git bisect good <- mark current head as good |
|
|
|
otherwise, reboot into a good kernel instead, and do (surprise surprise, |
|
git really is very intuitive): |
|
|
|
git bisect bad <- mark current head as bad |
|
|
|
and whatever you do, git will select a new half-way point. Do this for a |
|
while, until git tells you exactly which commit was the first bad commit. |
|
That's your culprit. |
|
|
|
It really works wonderfully well, except for the case where there was |
|
_another_ commit that broke something in between, like introduced some |
|
stupid compile error. In that case you should not mark that commit good or |
|
bad: you should try to find another commit close-by, and do a "git reset |
|
--hard <newcommit>" to try out _that_ commit instead, and then test that |
|
instead (and mark it good or bad). |
|
|
|
You can do "git bisect visualize" while you do all this to see what's |
|
going on by starting up gitk on the bisection range. |
|
|
|
Finally, once you've figured out exactly which commit was bad, you can |
|
then go back to the master branch, and try reverting just that commit: |
|
|
|
git checkout master |
|
git revert <bad-commit-id> |
|
|
|
to verify that the top-of-kernel works with that single commit reverted. |
|
|
|
|