kernel git bisect question

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?

Thanks
Mark

You can count on the build system to take care.
It is very rare that the build system does not handle this.

Lately we fixed a bug where we did not properly handled when a file was renamed from *.S to *.c. But you will most likely not hit this.

Sam

Thanks

Mark

I don't usually do a make clean. Although my ktest.pl (see tools/testing/ktest) does do a make mrproper between builds (unless you specify not to).

There are some cases in the kernel that can cause bugs if you do not do a make clean, so if your bisect hits one of those rare cases, you may introduce a bug in the build. But that is extremely rare. Like I said, when I use to do manual git bisects, I never did a make clean. But now that I do automate bisects, and do not need to babysit the box, I let ktest do those cleans.

-- Steve

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

harley:/usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
Initialized empty Git repository in /usr/src/linux-2.6-allstable/.git/
remote: Counting objects: 1971777, done.
remote: Compressing objects: 100% (332768/332768), done.
remote: Total 1971777 (delta 1640306), reused 1952128 (delta 1621734)
Receiving objects: 100% (1971777/1971777), 402.59 MiB | 2.15 MiB/s, done.
Resolving deltas: 100% (1640306/1640306), done.

harley:/usr/src # cd linux-2.6-allstable
harley:/usr/src/linux-2.6-allstable # git bisect start
harley:/usr/src/linux-2.6-allstable # git bisect bad v2.6.36
harley:/usr/src/linux-2.6-allstable # git bisect good v2.6.35
Bisecting: 5103 revisions left to test after this (roughly 12 steps)
[78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c] Merge branch 'bkl/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing

harley:/usr/src/linux-2.6-allstable # git bisect bad
Bisecting: 2414 revisions left to test after this (roughly 11 steps) [6ba74014c1ab0e37af7de6f64b4eccbbae3cb9e7] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6

harley:/usr/src/linux-2.6-allstable # git bisect bad (Why did this one give me a 2.6.35-rc1 Makefile)
Bisecting: 1366 revisions left to test after this (roughly 10 steps) [b7753c8cd51dce67a0b152efb456a21ff1cc241b] cfg80211: fix dev <-> wiphy typo

harley:/usr/src/linux-2.6-allstable # git bisect bad (Still a 2.6.35-rc1 Makefile)
Bisecting: 643 revisions left to test after this (roughly 9 steps) [ef2519b1dd3994074e3e438d67f2d91d07c3a5a8] netxen: fail when try to setup unsupported features

harley:/usr/src/linux-2.6-allstable # git bisect bad (Still a 2.6.35-rc1 Makefile)
Bisecting: 319 revisions left to test after this (roughly 8 steps)
[14599f1e341ee219abdd15f4eee5872d6f2d29f1] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6

harley:/usr/src/linux-2.6-allstable # git bisect bad (Why did this one give me a 2.6.34 Makefile)
Bisecting: 161 revisions left to test after this (roughly 7 steps) [86cc652dfe57f365533cf2e64e08ff37a510d42e] iwlwifi: remove debug frame dumping

Thanks again
Mark

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.

Sam

OK, thanks again. I'll continue on with the process then.

Mark

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

Understood. I was starting to think it was me. Thanks.

Mark