Johannes Sixt wrote:
If you are pretty sure that the bug you are looking for was *not* introduced in the branch that was subtree-merged, you can mark it as "good" like so: $ git bisect start kvm-69 kvm-70 $BRANCH where $BRANCH is the most recent commit on the subtree-merged branch. Watch out that you do *not* accidentally pick the *merge* commit that merged the branch in, but the (second) parent[*], the one that was merged in. Then your bisect sequence won't ever end up in that branch.
Unfortunately, it is fairly likely that the bug was indeed introduced by the merge, since most of the commits in that repository come via that merge.
It is possible that the bug exists in that branch (which you need to build as pure qemu, not kvm), but again, it is more likely that the bug is an interaction between a qemu feature introduced during the merge, and the existing kvm glue code.
One way around this is to redo the merge from the point git bisect suggests, but that is difficult, time consuming, and error prone. It also needs a lot of familiarity with the code.
Fortunately, long term the problem is going away with qemu upstream gaining kvm support.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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
