On Fri, 12 May 2006, Andrew Morton wrote: > > Trying to find a recently-merged box-killer in Len's tree: > > bix:/usr/src/git26> cat .git/branches/git-acpi > git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test > > git-checkout git-acpi Just for others: if you already have a Linux repo, this is the perfect time to do git clone --reference <old-linux-repo> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 to get that linux-acpi-2.6 repository. And for Junio: good job on that "--reference" flag. I used to do a local clone and then force an update, this was much better. > git-bisect reset > git-bisect start > git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e > git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9 > > And it led me to > > bix:/usr/src/git26> git-bisect good > 9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit > > which isn't a buggy patch. Well, to see what's up, do "git bisect visualize". That tends to not only help bisect things (for when you want to pick a different bisection point), it's also a wonderfully visual tool to what the f*%& happens when something goes wrong. Anyway, when I replay your log: > bix:/usr/src/git26> cat .git/BISECT_LOG > git-bisect start > # good: [ff2fc3e9e3edb918b6c6b288485c6cb267bc865e] ACPI: EC acpi-ecdt-uid-hack > git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e > # bad: [9011bff4bdc0fef1f9a782d7415c306ee61826c9] ACPI: delete newly added debugging macros in processor_perflib.c > git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9 > # good: [c52851b60cc0aaaf974ff0e49989fb698220447d] P-state software coordination for speedstep-centrino > git-bisect good c52851b60cc0aaaf974ff0e49989fb698220447d > # good: [7e1f19e50371e1d148226b64c8edc77fec47fa5b] ACPI: UP build fix for bugzilla-5737 > git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b I definitely get the same "9011bff4bdc0fef1f9a782d7415c306ee61826c9 is first bad commit" result, and going along visually at every point makes it very very obvious that git-bisect is right. (In fact, the _most_ visually obvious way to do it is to do this: git bisect reset git bisect start git bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e git bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9 git bisect visualize & git bisect good c52851b60cc0aaaf974ff0e49989fb698220447d .. go into the "file" menu, and select "re-read references" .. git-bisect good 7e1f19e50371e1d148226b64c8edc77fec47fa5b .. do "re-read references" again .. and you'll see exactly what "git bisect" is doing). You claimed that the previous commit (7e1f19..) was good, and that 9011bff.. itself was bad). So if that was true, then it really _was_ that 9011bff.. commit that caused it. > What did I do wrong this time? You did nothing wrong, unless your _testing_ was wrong, and one of your "git bisect good" entries should have been bad, or the other way around (you booted into the wrong kernel, so you thought something was ok when it wasn't). Why are you so sure that git bisect gave the wrong answer? This is ACPI, after all. For all we know, subtle cache-effects could break it. "git bisect" sadly won't help with bugs that show up due to some other subtle interaction.. Anyway, my first guess would be that you might have marked something good or bad that wasn't. How sure are you about that initial "git bisect bad" you did? Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html