{"thread":{"id":"2392","subject":"[PATCH] Add bug isolation howto, scraped from Linus.","startedAt":"2005-11-08T02:45:25Z","lastAt":"2005-11-08T02:45:25Z","messageCount":1,"participants":["Jon Loeliger"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"11296","messageId":"E1EZJUD-0001yw-Io@jdl.com","threadId":"2392","inReplyTo":null,"subject":"[PATCH] Add bug isolation howto, scraped from Linus.","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-08T02:45:25Z","receivedAt":"2005-11-08T02:45:25Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nSigned-off-by: Jon Loeliger <jdl@freescale.com>\n\n---\n\nYou know, eventually this will all be fully documented.\nThe trick is to catch Words To The Wise as the flow past you.\n\n\n Documentation/howto/isolate-bugs-with-bisect.txt |   65 ++++++++++++++++++++++\n 1 files changed, 65 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/howto/isolate-bugs-with-bisect.txt\n\napplies-to: 71213f57daeac18b52439d6d8acd5baba9bf05c7\n4e0819ff782b33d149634a397fb539f4759ef1f4\ndiff --git a/Documentation/howto/isolate-bugs-with-bisect.txt b/Documentation/howto/isolate-bugs-with-bisect.txt\nnew file mode 100644\nindex 0000000..4009495\n--- /dev/null\n+++ b/Documentation/howto/isolate-bugs-with-bisect.txt\n@@ -0,0 +1,65 @@\n+From:\tLinus Torvalds <torvalds () osdl ! org>\n+To:\tgit@vger.kernel.org\n+Date:\t2005-11-08 1:31:34\n+Subject: Real-life kernel debugging scenario\n+Abstract: Short-n-sweet, Linus tells us how to leverage `git-bisect` to perform\n+\tbug isolation on a repository where \"good\" and \"bad\" revisions are known\n+\tin order to identify a suspect commit.\n+\n+\n+How To Use git-bisect To Isolate a Bogus Commit\n+===============================================\n+\n+The way to use \"git bisect\" couldn't be easier.\n+\n+Figure out what the oldest bad state you know about is (that's usually the \n+head of \"master\", since that's what you just tried to boot and failed at). \n+Also, figure out the most recent known-good commit (usually the _previous_ \n+kernel you ran: and if you've only done a single \"pull\" in between, it \n+will be ORIG_HEAD).\n+\n+Then do\n+\n+\tgit bisect start\n+\tgit bisect bad master\t\t<- mark \"master\" as the bad state\n+\tgit bisect good ORIG_HEAD\t<- mark ORIG_HEAD as good (or\n+\t\t\t\t\t   whatever other known-good \n+\t\t\t\t\t   thing you booted laste)\n+\n+and at this point \"git bisect\" will churn for a while, and tell you what \n+the mid-point between those two commits are, and check that state out as \n+the head of the bew \"bisect\" branch.\n+\n+Compile and reboot.\n+\n+If it's good, just do\n+\n+\tgit bisect good\t\t<- mark current head as good\n+\n+otherwise, reboot into a good kernel instead, and do (surprise surprise, \n+git really is very intuitive):\n+\n+\tgit bisect bad\t\t<- mark current head as bad\n+\n+and whatever you do, git will select a new half-way point. Do this for a \n+while, until git tells you exactly which commit was the first bad commit. \n+That's your culprit.\n+\n+It really works wonderfully well, except for the case where there was \n+_another_ commit that broke something in between, like introduced some \n+stupid compile error. In that case you should not mark that commit good or \n+bad: you should try to find another commit close-by, and do a \"git reset \n+--hard <newcommit>\" to try out _that_ commit instead, and then test that \n+instead (and mark it good or bad).\n+\n+You can do \"git bisect visualize\" while you do all this to see what's \n+going on by starting up gitk on the bisection range.\n+\n+Finally, once you've figured out exactly which commit was bad, you can \n+then go back to the master branch, and try reverting just that commit:\n+\n+\tgit checkout master\n+\tgit revert <bad-commit-id>\n+\n+to verify that the top-of-kernel works with that single commit reverted.\n+\n---\n0.99.9.GIT\n"}]}