I'm trying to bisect kernel bug A, but I keep running into kernel bug B which causes a crash on boot. (But was fixed, so I don't need to think about it much.) that is, my revision history is something like: G...........G......XXXXXXXXXX.....B...............B G = good B = bad X = I can't tell While I can do things like "git-reset --hard HEAD~250" to try to get past the problem, it's an annoying bit of guessing to find good values, and if my problem is one some branch, I'd rather explore a different branch. How much nicer, I couldn't help thinking, if bisection could be told to look for a ratio other than 1/2. Then I could ask for the 1/3 or 2/3 point instead. That would also be helpful in cases where the "good" or "bad" cases differ significantly in testing pain. For example, if "bad" forces an fsck, or if "good" takes a couple of hours of stress-testing to be really sure. I *think* it's just a tweak to builtin-rev-list.c:halfway(), but the code that calls that is rather intricate. So if anyone feels like attempting it... Adding the relevant UI to git-bisect would be relatively straightforward. A new command to re-bisect from the initial state would allow evading unbuildable commits, and maybe a way to set a preferred split ratio. - To unsubscribe from this list: 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
