Re: git bisect with history manipulation

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 23, 2006, 15:34 UTC
Message-ID: <Pine.LNX.4.64.0610230826080.3962@g5.osdl.org>
In-Reply-To: <a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com>

On Mon, 23 Oct 2006, Kalle Pokki wrote:

> 
> So is there any way to insert a few patches to an arbitrary point
> backwards in time and start bisecting from that to the present time?
> Or am I thinking this somehow all wrong?

It's possible, but you have to do it the patch-application manually at each stage, so it's not a lot of fun. I've had to do it for the opposite reason: hunting down a bug with "git bisect" when there was _another_ unrelated bug that I already had fixed, but that made it impossible to test for the first one. Again, in order to see the first one, I did git bisect, but then at each stage applied the fix for the second one if needed.

So what you would do is to simply do the bisect _as_if_ those patches weren't there, and then apply the patches on top of the kernel that "git bisect" suggests. Then (and this is important), when you mark the result good or bad, don't use just "git bisect good/bad" - but name explicitly the commit that you applied your patch-series on.

(This gets a bit easier if you instead of actually cherry-picking the patches you want to apply, just apply it as a single patch _without_ committing it - then all your changes will be effectively "invisible" to git bisect anyway, and you don't need to do much of anything special, except do a "git checkout -f" to remove the patch before you say "that was bad" or "that was good").

HOWEVER. It's quite possibly easier to just do it the other way: if your series of patches causes problems when rebased on top of a newer kernel, just bisect your rebased series itself (at which point it's all a totally normal "git bisect", and you don't need to do anything special). It may be that once you see _which_ patch in the series caused problems, you'll immediately say "Oh, duh, that got mis-merged" or (perhaps more likely) by pointing to a particular commit it will point to a certain area that changed and you suddenly realize _why_ the series caused a problem.

So depending on the problem, you can try two different approaches.

It might make sense to extend "git bisect" with a "apply this patch at each point" capability, but that doesn't exist right now. If you do end up going that way, and automate it, please do send the patches out for discussion.

		Linus