On Thu, 1 Mar 2007, Linus Torvalds wrote:
>
> Once you have that, you now actually have a way to "correct" for that
> known bug, and by correcting for the known bug, you now *can* separate the
> behaviour of the two bugs:
>
> - You can now re-do a totally mindless git bisection for the *other* bug,
> but what you now need to do is that at each bisection step, you look at
> whether the bisection point has the known bug, and if so, you apply the
> known fix for that known bug, and thus you can test the kernel
> *without* the interaction of the bug you already found.
>
> This makes bisection a lot less automated (you have to apply the "fix" for
> the other bug at each step)
Side note: it's still usually fairly easy. Especially if you have a known
fix for the other bug, you can usually just do the equivalent of
git cherry-pick <fixcommit>
at each point during this bisect (or just have a known patch that you keep
applying and un-applying), and you're largely done.
Of course, if the area with the fix keeps changing, or if the fix is
really intrusive and nasty, this gets hairy, but at least in this case the
patch is fairly trivial and it shouldn't cause any trouble at all to do
this.
The only real down-side is just the mindless extra work, and the possible
added confusion you get from modifying the history at the points you're
testing. "git bisect" is not necessarily happy about auto-picking a new
bisection point with a dirty tree, for example, so before you mark
something "good" or "bad", you should generally try to do so with a clean
git tree (ie if you apply a patch at each stage, do "git reset --hard" to
remove the patch before you do the "git bisect bad/good" stage).
Similarly, especially at the end of the bisection run, if you actually use
"git cherry-pick" to *add* a commit, the bisection will now take that
added commit into account when trying to pick the next commit to check,
which is not what you really want. It probably doesn't matter that much
during the early stages (when bisection is really jumping around wildly
anyway, and one commit more or less doesn't really matter), but again, it
might be a good idea to make a habit of undoing the cherry-pick, the same
way you'd undo a patch (eg "git reset --hard HEAD^" would do it, if you
have exactly one cherry-pick that you tested).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
