{"thread":{"id":"5858","subject":"git bisect idea: Asymmetric split points","startedAt":"2006-10-08T23:43:08Z","lastAt":"2006-10-09T00:19:58Z","messageCount":2,"participants":["Peter Osterlund","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"28437","messageId":"m38xjqfk6r.fsf@telia.com","threadId":"5858","inReplyTo":null,"subject":"git bisect idea: Asymmetric split points","fromName":"Peter Osterlund","fromEmail":"petero2@telia.com","sentAt":"2006-10-08T23:43:08Z","receivedAt":"2006-10-08T23:43:08Z","isPatch":false,"sender":{"key":"petero2@telia.com","avatar":null},"body":"I was using git bisect today when trying to track down a random kernel\nhang during boot. Since the hang is random, ie it only hangs during\nsome boots, identifying a bad version is easier than identifying a\ngood version. If it hangs during one boot, the kernel is clearly bad,\nbut if it doesn't hang I can't be sure if it's good or bad. I have to\ntest several times to be reasonably sure that a kernel is good.\n\nIn this scenario identifying a bad kernel is easier than identifying a\ngood kernel. This means that if I want to find the guilty commit as\nfast as possible the best strategy is not to split the remaining\ncommit list in half. In this case it would be better to split closer\nto a known bad commit.\n\nYou can also imagine cases where identifying a bad version is more\ncostly than identifying a good one. One example would be if a bad\nkernel has nasty side effects, such as file system corruption, that\nyou have to fix up before you can continue bisecting.\n\nTo handle these cases more efficiently, I think it would be nice to be\nable to tell git bisect where the bisection point is wanted, for\nexample by specifying a percentage.\n\nDoes this sound like a good idea? Would it be hard to implement?\n\n-- \nPeter Osterlund - petero2@telia.com\nhttp://web.telia.com/~u89404340\n"},{"id":"28439","messageId":"Pine.LNX.4.64.0610081711370.3952@g5.osdl.org","threadId":"5858","inReplyTo":"m38xjqfk6r.fsf@telia.com","subject":"Re: git bisect idea: Asymmetric split points","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-09T00:19:58Z","receivedAt":"2006-10-09T00:19:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 9 Oct 2006, Peter Osterlund wrote:\n> \n> Does this sound like a good idea? Would it be hard to implement?\n\nIt should be very easy to implement.\n\nSee builtin-rev-list.c: find_bisection(), which has a _very_ simple way of \ntrying to find the best commit. It just counts the distance from the \ncommit:\n\n\tdistance = count_distance(p);\n\tclear_distance(list);\n\nwhere \"distance\" is really \"how many commits will this cover\".\n\nIf you wanted to get as close to (say) 75% of the total list of commits as \npossible, you should just do something like\n\n\toptimal = nr * percent / 100;\n\thow_close = abs(optimal - distance);\n\tif (how_close < closest) {\n\t\tbest = p;\n\t\tclosest = how_close;\n\t}\n\ninstead of what we do now (which is just to say that \"since we want to get \nhalf-way, we want to make the biggest distance from _both_ 0 and from \n\"nr\", which is what it calculates with\n\n - If we're closer to \"nr\" than to 0 (ie the difference between nr and \n   distance is smaller than the difference between distance and 0), pick \n   the smaller difference:\n\n\tif (nr - distance < distance) \n\t\tdistance = nr - distance;\n\n - if this new distance is larger than any distance we've seen so far, \n   this is the best commit so far:\n\n\tif (distance > closest) {\n\t\tbest = p;\n\t\tclosest = distance;\n\t}\n\nand notice how this is really just a special case of the percentage thing \nwhen percent is 50%.\n\n\t\t\tLinus\n"}]}