>
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.
