From: Valdis.Kletnieks@vt.edu
To: Frans Pop <elendil@planet.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: git bisect questions...
Date: Thu, 06 May 2010 10:00:03 -0400 [thread overview]
Message-ID: <24885.1273154403@localhost> (raw)
In-Reply-To: Your message of "Tue, 04 May 2010 18:08:44 +0200." <201005041808.44875.elendil@planet.nl>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
On Tue, 04 May 2010 18:08:44 +0200, Frans Pop said:
> Valdis.Kletnieks@vt.edu wrote:
> > 1) I look at 'git bisect visualize', and I see a nice merge point that I
> > am fairly sure will (a) bisect as good and (b) trim out a *lot* of
> > ancestor commits in one shot. If I do a 'git reset --hard <merge
> > commit>', will that make the next 'git bisect' do what I want?
>
> Yes.
>
> > 2) I'm down to the last 100 or so commits, and I have a at least 3 'git
> > bisect skip' in there already because of a (presumably) unrelated oops.
> > I'm pretty sure that commit 10fd883ce384706f88554a0b08cc4d63345e7d8b is
> > the fix - how do I logically move that commit to right after the commit
> > 22dd82a3f5ceef72be19e502418823a2f8801ed0 which introduced the oops, so
> > I can bisect through the 70 or so commits in between? I know it involves
> > "git cherrypick", but have no clue how to do it...
>
> One way is, before *each* compilation after a 'git bisect good/bad', to do
> a 'git cherry-pick 10fd883ce3847'. This means you don't actually move it
> after the commit that causes the problem, but you do add it on top for
> your compilation.
>
> But that means that after testing the build you can no longer do a simple
> 'git bisect good/bad' as that would tag the cherry-picked commit instead of
> the one you tested.
>
> So instead you have to do 'git bisect good/bad HEAD^' (assuming you did a
> single cherry-pick) [1].
> This will automatically "remove" the cherry-picked commit again, which is
> why you have to add it back for your next iteration.
Thanks muchly - after 2 well-chosen 'git resets' and 3 cherry-picks, I'm now
well on my way to bisect down to the offending commit with no further issues
(other than getting interrupted by other tasks, but that's my problem not
lkml's). If you're ever in this corner of rural Virginia, I owe you a
beverage-of-choice. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
prev parent reply other threads:[~2010-05-06 14:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-04 14:23 git bisect questions Valdis.Kletnieks
2010-05-04 16:08 ` Frans Pop
2010-05-06 14:00 ` Valdis.Kletnieks [this message]
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=24885.1273154403@localhost \
--to=valdis.kletnieks@vt.edu \
--cc=elendil@planet.nl \
--cc=linux-kernel@vger.kernel.org \
/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