{"thread":{"id":"8750","subject":"If anyone feels like hacking git-rev-list --bisect...","startedAt":"2007-06-27T18:53:37Z","lastAt":"2007-06-27T18:53:37Z","messageCount":1,"participants":["linux@horizon.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45932","messageId":"20070627185337.1107.qmail@science.horizon.com","threadId":"8750","inReplyTo":null,"subject":"If anyone feels like hacking git-rev-list --bisect...","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2007-06-27T18:53:37Z","receivedAt":"2007-06-27T18:53:37Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"I'm trying to bisect kernel bug A, but I keep running into kernel bug\nB which causes a crash on boot.  (But was fixed, so I don't need to think\nabout it much.)\n\nthat is, my revision history is something like:\n\nG...........G......XXXXXXXXXX.....B...............B\nG = good\nB = bad\nX = I can't tell\n\n\nWhile I can do things like \"git-reset --hard HEAD~250\" to try to get past\nthe problem, it's an annoying bit of guessing to find good values, and\nif my problem is one some branch, I'd rather explore a different branch.\n\nHow much nicer, I couldn't help thinking, if bisection could be told\nto look for a ratio other than 1/2.  Then I could ask for the 1/3 or 2/3\npoint instead.\n\nThat would also be helpful in cases where the \"good\" or \"bad\" cases\ndiffer significantly in testing pain.  For example, if \"bad\" forces\nan fsck, or if \"good\" takes a couple of hours of stress-testing\nto be really sure.\n\nI *think* it's just a tweak to builtin-rev-list.c:halfway(), but the\ncode that calls that is rather intricate.\n\nSo if anyone feels like attempting it...\n\nAdding the relevant UI to git-bisect would be relatively straightforward.\nA new command to re-bisect from the initial state would allow evading\nunbuildable commits, and maybe a way to set a preferred split ratio.\n"}]}