Re: kernel git bisect question

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 2011-03-11 at 19:37 +0100, Sam Ravnborg wrote:
> On Fri, Mar 11, 2011 at 01:31:53PM -0500, Mark Hounschell wrote:
> > On 03/10/2011 04:54 PM, Steven Rostedt wrote:
> > > On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
> > >> Between git bisect [good | bad ]s should I always "make clean" or can I
> > >> count on the build system to take care of everything properly?
> > > 
> > 
> > I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
> > Here is exactly what I've done. Why after my second "git bisect bad" do
> > I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
> > for 2.6.34??
> 
> The development is not linear.
> So you see a commit developed on top of 2.6.34 that was included in 2.6.35.
> This is normal.

Right.

Mark, don't be embarrassed, this is a common question for those that
start using git bisect. Because of the way git merges branches, you may
end up in an old version of a kernel, while looking between two newer
versions.



    v2.6.36
        |
        +
        |\
        | \
v2.6.35 +  \
        |   +---- developers branch
        |  /
        | /
        |/
        +--- v 2.6.34
        |

If a developer branched off of 2.6.34 and then his work got merged after
v2.6.35, your bisect may easily go into that developers branch between
2.6.35 and 2.6.36, where you will suddenly see 2.6.34 appear and
disappear within bisect iterations. IOW, don't trust what you see in the
Makefile ;)

Understand?

-- Steve