I was using git bisect today when trying to track down a random kernel hang during boot. Since the hang is random, ie it only hangs during some boots, identifying a bad version is easier than identifying a good version. If it hangs during one boot, the kernel is clearly bad, but if it doesn't hang I can't be sure if it's good or bad. I have to test several times to be reasonably sure that a kernel is good. In this scenario identifying a bad kernel is easier than identifying a good kernel. This means that if I want to find the guilty commit as fast as possible the best strategy is not to split the remaining commit list in half. In this case it would be better to split closer to a known bad commit. You can also imagine cases where identifying a bad version is more costly than identifying a good one. One example would be if a bad kernel has nasty side effects, such as file system corruption, that you have to fix up before you can continue bisecting. To handle these cases more efficiently, I think it would be nice to be able to tell git bisect where the bisection point is wanted, for example by specifying a percentage. Does this sound like a good idea? Would it be hard to implement? -- Peter Osterlund - petero2@xxxxxxxxx http://web.telia.com/~u89404340 - 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