linux-kernel - Re: kernel git bisect question

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: <1299869490.9910.49.camel@gandalf.stny.rr.com>
Date:	Fri, 11 Mar 2011 13:51:30 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Mark Hounschell <markh@...pro.net>,
	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: kernel git bisect question

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




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