Re: 2.6.29 on MacBook 2,1 fails to reboot

[Alistair John Strachan <alistair@devzero.co.uk>]

On Monday 30 March 2009 08:33:06 Trenton D. Adams wrote:
[snip]
> Then, I mark the current (something in 2.6.28) one as good...
> # good: [86b3aa390b4b9925f16a21b98441fd7abdb9fff2] Merge branch
> 'topic/ca0106' into to-push
> git bisect good 86b3aa390b4b9925f16a21b98441fd7abdb9fff2
>
> And I get this...
> tdamac linux # git bisect good
> Bisecting: 89 revisions left to test after this
> [b83923a3931a43df7397a7491f0c9d9b9d46624a] ALSA: hda - minor HDMI code
> cleanups tdamac linux # make kernelversion
> 2.6.27
>
> So, if I mark that as good (arbitrarily because it's pre 2.6.28 which
> I assume is good), it jumps back to pre 2.6.28 release
> tdamac linux # git bisect good
> Bisecting: 46 revisions left to test after this
> [0ff555192a8d20385d49d1c420e2e8d409b3c0da] Merge branch 'fix/hda' into
> topic/hda tdamac linux # make kernelversion
> 2.6.28-rc8
>
> And, if I mark the 2.6.27 one as bad, it just remains on 2.6.27.

Don't worry about the kernel version it generates. Git bisections traverse 
merged branches, including those that weren't rebased before being merged (in 
fact the preferred work flow). I usually add "-bisect" to CONFIG_LOCALVERSION 
so I can isolate my work in progress bisection from system kernels.

You can trust git to involve only relevant commits between your initial "good" 
and "bad" markers; don't add more unless you have to. Sometimes you may need 
to "shift" the bisection midpoint if you encounter build breakage. You should 
be able to find comments Linus made on the subject by searching the LKML 
archive for "git bisect visualize".

-- 
Cheers,
Alistair.