Andy Lutomirski <luto@xxxxxxxxxx> writes: > I'm currently bisecting a Linux bug on my laptop. The starting good > commit is v4.4-rc3 and the starting bad commit is v4.4-rc7. > Unfortunately, anything much older than v4.4-rc3 doesn't boot at all. > > I'd like to say: > > $ git bisect merge-to v4.4-rc3 > > or similar. The effect would be that, rather than testing commits in > between the good and bad commits, it would test the result of merging > those commits with v4.4-rc3. > > Obviously the syntax could be tweaked a lot, but I think the concept > could be quite handy. I do not think such an option or "concept" belongs to "git bisect". When "git bisect" checks out a commit to test, it is entirely up to you how to decide if the commit is good or bad. Your example is to work on the Linux kernel project, so the way to test might be "make mrproper && make bzImage && ... && reboot" to see if the result boots. There is nothing that prevents you from changing the test procedure to be prefixed by "if the version to test is older than version X, merge the commit to version X first before doing anything else". The key thing to realize is that "merge the version X" is not universally useful "fixup" to deal with unbuildable or untestable commit. In some situations, "I have this fix-up patch I need to apply for versions that are older than Y before I can test" may be a lot more appropriate "fixup". So "merge-to" does not deserve to be the first-class "concept". "Here is a script to fix up the tree that 'git bisect' tells me to test" instead might be a general enough concept, and you might say $ git bisect --fixup "./my-fixup-script" and have "git merge --no-commit v4.4-rc3" in "my-fixup-script", perhaps. But at that point, it would be as easy as adding whatever you would write in my-fixup-script at the beginning of the script you are already using (and if you aren't, read up on "git bisect run") to perform the test. So... -- 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