Am 25.11.2013 12:37, schrieb Michael S. Tsirkin: > On Mon, Nov 25, 2013 at 10:53:44AM +0100, Paolo Bonzini wrote: >> Il 24/11/2013 12:04, Stefan Weil ha scritto: >>> Do we really need this? It only makes git bisect iterations from >>> versions after 2013-11-19 to versions before that date easier. If a >>> typical git bisect needs 10 steps, then in the worst cast 5 of them >>> won't automatically run configure. This is normally not a big problem >>> because there is already a configuration, and many changes of file >>> configure don't change that configuration. >>> >>> It's always possible to run configure explicitly at each step of the >>> bisection process, so in case of doubt there is an easy fall-back >>> solution. Before I introduced automatic reconfiguration, calling >>> configure + make was normal for git bisect. >>> >>> I'd prefer to avoid code like this patch which is only marginally useful >>> in a very specific development use case. People who can run git bisect >>> will be able to help themselves if they really get a problem without the >>> patch. >> I think anything that makes it easier for users to do bisections instead >> of us, and anything that makes it easier to script bisections ("git >> bisect run"), is valuable. >> >> Thanks Michael, patch >> >> Acked-by: Paolo Bonzini <pbonz...@redhat.com> >> >> for 1.7 too. >> >> Paolo > IMHO it's helpful but it's too late for controversial patches now. > So I won't push this to Anthony unless Stefan reconsiders and acks.
If it helps you and Paolo (and maybe others), I don't mind if you push the patch. Technically it looks fine, therefore Acked-by: Stefan Weil <s...@weilnetz.de> Let me just add some information from my personal experience with git bisect. I don't run "git bisect" on QEMU very often - maybe once per month. "git bisect run" was never a feasible option because in most cases I had to inspect the output on QEMU's framebuffer. Nearly all bisections needed manual intervention, either because the configure options changed (removal of audio options), code was broken or for other reasons. On each step I try an incremental build first, if that fails, a clean build follows (I build always out of tree, so it's easy to really clean everything). Cheers, Stefan