Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: > Anyway, the idea of merging test commits up to some lowest common > denominator seems generally useful to me, and the idea of specifying a > 'prepare the checked-out tree' (as you suggested, where 'git merge > --no-commit whatever' would be specified) would also be handy, and > both of these are useful even in cases where git bisect run isn't > being used. Yes, I didn't mean to say "bisect run" is always great. What I was hinting at was that even if you are _not_ using "bisect run" (which almost always _requires_ you to write a small script that does the test and says yes/no), once you start working on a project that is sufficiently complex (like bisecting a regression in the Linux kernel), your procedure to build and test a single revision becomes complex enough that it is worth to write and use a small script for a single step _anyway_. And with that in mind, "how do I prepare the checked-out tree for building and testing" can be part of that script. Which in turn means there is nothing to add to "bisect", not even the "--fixup my_fixup_script" I alluded to, let alone "--merge-to" that is way too specific to the case you happened to have had before you sent your message. -- 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