On Wed, Dec 30, 2015 at 12:09 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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... git bisect run is great, but it's not so great when the test process is "sudo make modules_install && sudo make install && reboot", then boot new kernel, then run emacs, then see if it worked... There doesn't appear to be a 'git bisect run' option to pause and wait for an explicit user request to continue, unfortunately. --Andy -- 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