On Mon, Jan 4, 2016 at 12:31 PM, Junio C Hamano <gits...@pobox.com> wrote: > Andy Lutomirski <l...@amacapital.net> writes: > >> 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. > > That is expected to be part of your run script, as that is a custom > and specialized need your bisection has. > > It still will not work when the test procedure involves rebooting, > but "git bisect" does not require you to install and reboot the same > machine you are running the bisection on, i.e. the test process > could be "build && scp there && ssh there reboot && see if comes up" > ;-) >
All I'm going for is simplicity. I was bisecting on my laptop, and I couldn't reproduce on a VM, so I wasn't going to use 'git bisect run', because git bisect run doesn't support my use case. 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
