git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Kalle Pokki <kalle.pokki@iki.fi>
Cc: git@vger.kernel.org
Subject: Re: git bisect with history manipulation
Date: Mon, 23 Oct 2006 08:34:40 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0610230826080.3962@g5.osdl.org> (raw)
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

  reply	other threads:[~2006-10-23 15:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a425f86c0610230718i556537dei9a4b2a5fa8d7f003@mail.gmail.com>
2006-10-23 14:22 ` git bisect with history manipulation Kalle Pokki
2006-10-23 15:34   ` Linus Torvalds [this message]
2006-10-23 15:42     ` Jakub Narebski
2006-10-23 15:59       ` Linus Torvalds
     [not found]   ` <20061023114738.f77efec3.seanlkml@sympatico.ca>
2006-10-23 15:47     ` Sean
2006-10-23 16:19       ` Jakub Narebski
     [not found]         ` <20061023122527.4c095580.seanlkml@sympatico.ca>
2006-10-23 16:25           ` Sean
2006-10-23 16:21       ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0610230826080.3962@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=git@vger.kernel.org \
    --cc=kalle.pokki@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).