lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201005041808.44875.elendil@planet.nl>
Date:	Tue, 4 May 2010 18:08:44 +0200
From:	Frans Pop <elendil@...net.nl>
To:	Valdis.Kletnieks@...edu
Cc:	linux-kernel@...r.kernel.org
Subject: Re: git bisect questions...

Valdis.Kletnieks@...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.

Cheers,
FJP

[1] Or you can specify the commit ID of the commit you're really testing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ