Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/