{"thread":{"id":"3340","subject":"bisect ends with a commit marked good and bad","startedAt":"2006-02-15T07:19:32Z","lastAt":"2006-02-15T08:01:01Z","messageCount":2,"participants":["Sanjoy Mahajan","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16192","messageId":"E1F9Gwm-0001Dy-3b@approximate.corpus.cam.ac.uk","threadId":"3340","inReplyTo":null,"subject":"bisect ends with a commit marked good and bad","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2006-02-15T07:19:32Z","receivedAt":"2006-02-15T07:19:32Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"In doing a huge bisect (from 1875 or so revisions but fortunately\nlog(anything) is not too big) to chase a S3 sleep bug (bugme #5989), I\nalso noticed another problem.  In several 'good' kernels, where S3\nsleep-wake worked twice, the fan would not turn on despite the\ntemperature getting high, after the system went through two sleep-wake\ncycles.  [In the 'bad' kernels the system hangs on the second sleep, so\nI couldn't collect any data about the fan.]\n\nThe result is that, for several kernels, I got free bisect data about\nthis second bug.  I tried feeding this data to a fresh bisect, but\nbisect says that one particular commit is good and bad.  Here's the\nscript to run bisect:\n\n  #!/bin/bash -x\n  bad=\"a2d823bf ee408c79 d1138cf0\"\n  good=\"0f442aa2 49799291 4a90c7e8\"\n  git bisect start\n  for r in $bad  ; do git-bisect bad  $r ; done\n  for r in $good ; do git-bisect good $r ; done\n\nThe output:\n\n  + bad='a2d823bf ee408c79 d1138cf0'\n  + good='0f442aa2 49799291 4a90c7e8'\n  + git bisect start\n  + for r in '$bad'\n  + git-bisect bad a2d823bf\n  + for r in '$bad'\n  + git-bisect bad ee408c79\n  + for r in '$bad'\n  + git-bisect bad d1138cf0\n  + for r in '$good'\n  + git-bisect good 0f442aa2\n  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad\n  + for r in '$good'\n  + git-bisect good 49799291\n  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad\n  + for r in '$good'\n  + git-bisect good 4a90c7e8\n  d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad\n\nAt first I thought it was impossible for a bug to behave this way, and\nconcluded that my data must be corrupt, since d1138cf0 is marked bad.\nBut on further thought, I'm not sure.  Maybe there are quadratic\ninteractions between patches.  For example, if a particular bug happens\nonly when two patches occur together?  No, that would result in the\nmerge of their branches being the problematic commit.  So I'm stuck.\nBefore I conclude that the data is corrupt and spend several hours\nretesting several kernels, I thought I'd ask for advice from the\nentomologists and bisectors.\n\nHow would I use gitk to show the those three good and three bad commits,\nand their spanning tree?  Neither the man entry nor the examples of its\nuse in git-bisect taught me enough to use it properly.\n\n-Sanjoy\n"},{"id":"16194","messageId":"7vpslpm4oy.fsf@assigned-by-dhcp.cox.net","threadId":"3340","inReplyTo":"E1F9Gwm-0001Dy-3b@approximate.corpus.cam.ac.uk","subject":"Re: bisect ends with a commit marked good and bad","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-15T08:01:01Z","receivedAt":"2006-02-15T08:01:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:\n\n> How would I use gitk to show the those three good and three bad commits,\n> and their spanning tree?  Neither the man entry nor the examples of its\n> use in git-bisect taught me enough to use it properly.\n\nThe way bisect narrows down bug hunting is to find a single\nregression.  IOW, the only question you can ask bisect is \"this\nolder one was known to be good, but somehow this new one is bad.\nIf it was caused by one bug introduced somewhere during the\ncourse of changes between the two, which one is it?\"\n\nSo you always start by giving one good and one bad (or one bad\nand one good, the order does not matter).  That leaves * as\nsuspects.\n\n    o---o---O---*---*---*---*---X---o\n         \\             /\n          *---*---*---*\n\n        O (good) X (bad)\n\nSince it is finding a single regression, o commits are\nirrelevant.  commits after bad one X may have fixed the bug but\nyou are not interested in it.  Commits before good one O might\nhave been broken in some other way, but we are looking for a\nsingle regression, so they do not really matter either.\n\nThen bisect suggests you one of (*) commits.  Not at random, but\nsomewhere midway.\n\n    o---o---O---*---*---*---*---X---o\n         \\             /\n          *---*---*---?\n\n        O (good) X (bad)\n\nIf ? is good, then three * suspects are good so you then have to\nworry about remaining four * between the first O and X.  That's\nhow you narrow things down.\n\nYou say a2d823bf is bad and 0f442aa2 is good.  However, the\na2d823bf is a proper ancestor of 0f442aa2.  That is, earlier it\nwas good but now it is good.  As if you are trying to locate the\ncommit that fixed the bug.  This is an impossible situation for\nthe bisect.\n\nSo your initial input may be truly good and bad commits, but\nthere might be more than one regression involved.\n\nTo look at the graph, you could do something like this:\n\nfor r in $good; do git tag good-$r $(git-rev-parse --verify $r); done\nfor r in $bad; do git tag bad-$r $(git-rev-parse --verify $r); done\ngitk $(git-rev-parse $good) $(git-rev-parse --not $bad)\n\nYou will notice there is only one bad-* way below all the good-*\nones.  Another possibility is maybe you have your good and bad\nswapped?\n"}]}