> I'd expect this to work: > > Â Â$ git bisect start > Â Â$ git bisect good > Â Â$ git bisect bad HEAD~100 So would I. I think the behavior of git bisect should be changed. Right now, it's trying to find the first bad commit. Instead, it should be trying to find the first commit where the code's good/bad state *changed*. IOW, it should be able to handle both of the following cases: good <--- oldest good good bad <--- the commit we want bisect to find bad bad <--- newest bad <--- oldest bad bad good <--- the commit we want bisect to find good good <--- newest It shouldn't matter which end we start on, so long as one end gets marks good, and the other end gets marked bad. Andrew -- 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