Linus Torvalds schrieb: > IOW, let's say that you really do bisect things down to a merge and cannot > see what the fault in that merge is, you can literally do > > # create a test-branch with the 'remote' side of the merge > git checkout -b test-branch merge^2 > > # rebase that remote side on top of the local side > git rebase merge^ > > and now you've linearized the merge temporarily just to be able to bisect > in that temporary branch what the bad interaction is. But once you've > bisected it, the temporary branch is again just junk - there's no real > value in saving it, because once you know _why_ the bug happened, you're > just better off going back to the original history and just fixing it (and > documenting the bug through the fix, rather than by addign extra-ugly > history). FWIW, the same thing in different words is written in section "Why bisecting merge commits can be harder than bisecting linear history" of Documentation/user-manual.txt. -- Hannes -- 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
