git bisect enhancements?

Guys,

So, I'm in the middle of a Git Bisect War. It all worked around 2.6.13-rc3 time, and doesn't now.

So I launched into some bisecting, and it is all going pretty smoothly so far. But I think there is an obvious enhancement that I would like to propose for discussion.

First, the problem I'm seeing is that the current top of tree hangs an mpc8555_cds_defconfig build. Bummer. Doesn't get past the traditional "uncompressing image..." message.

Two or three "good builds" into things, it proposes a new build at a272e24cc8751d125f9582befed0213a2a2b270f. Which I build and don't quite boot. It hangs after the IDE probe, and before the i2c probe. Bummer.

These are not bugs I was looking for.  Move along.

So I lie and claim "git bisect good", making a *scratch* note of where the "git bisect log" seems to think I am so that I might come back here and claim "git bisect bad" later.

The _next_ proposed split is at a272e24cc8751d125f9582befed0213a2a2b270f where I can clearly see using "git bisect visualize" that a much better, perhaps more quiescent choice is two commits later. The proposed bisect location is in the middle of a series of commits from paulus tinkering with the PPC merge tree. Two commits later, though, Linus has merged it in totally. It will be less "in the middle" of things and more quiescent. I want to "bump" the bisect point up two commits and _then_ build.

So, I'm proposing something like:

    $ git bisect bump +<n>
    $ git bisect bump -<n>

To move the bisection point "up" or "down" a commit chain.

Am I off in the weeds?

Thanks, jdl

Jon Loeliger <jdl@freescale.com> writes:

Hmph. Doesn't "bisect good" or "bisect bad" let you explicitly say which one is good or bad, instead of just taking what it suggests as the next midpoint?

On Wed, 2005-11-30 at 16:04, Junio C Hamano wrote:

Sure. But I'm proposing to alter the new bisection middle point. I don't know its status yet. I am just angling on hedging my bets of a "good midpoint" choice by finding something that is likely to be more stable than the proposed midpoint.

jdl

Jon Loeliger <jdl@freescale.com> writes:

You could "git reset --hard <that-commit-N-up-or-down>", compile, test and say "git bisect good" or "git bisect bad".

Even "N commits before" is not so easy. "git reset --hard bisect~2" would be 2 commits before what git-bisect suggested as long as that chain in question is a single strand of pearls. "N commits after" is a bit harder, especially when a merge is involved. But you are right. Bisect should be able to do what you can visually do with gitk.

Jon Loeliger <jdl@freescale.com> writes:

This is not about your "bump", but one thing that may worthwhile to try is bisect enhancements Linus did a couple of days ago, to let you limit the number of commits tried by specifying the area you are interested in.

If may not help if only thing you know is that i2c probe is not what you are looking for, but if you know what area is suspect, say arch/powerpc and include/asm-powerpc (just taken randomly, I do not even know if you work in that area), it lets you say:

	$ git bisect reset
	$ git bisect start arch/powerpc include/asm-powerpc
        $ git bisect good v2.6.13-rc3
        $ git bisect bad master

What is interesting is that this cuts down the commits to be inspected to only the ones that touch the specified paths. So without the path specifier, you may need to bisect 5000 commits in total, but with the commits limited to the ones that touch these two example directories, you would need to bisect 247 commits, which is only a fraction of the original.

On Wed, 30 Nov 2005, Jon Loeliger wrote:

No, but we already have it.

If you decide to select a new bisection point by hand, just do it. It's called

	git reset --hard <new-bisect-point>

and it will simply move the bisect branch to the new point.

Then, compile and test that, and use "git bisect good/bad" as necessary.

Now, I agree that maybe I could have made that a bit more obvious, but it should all work.

Same goes for the case where "git bisect" selects a point that happens to have a different problem than the one you were looking for. Instead of saying "git bisect good" (or bad) and praying you got it right, just do that "git bisect visualize" and select another point entirely, and do that same "git reset --hard" thing, and leave the one you don't know about alone.

Of course, if you make a bad selection, you might have that problem again, or more commonly, you'll just have to test more kernels because your selection wasn't as close to "midway" as the one "git bisect" had selected for you. But you'll get there eventually.

[ Now, the _real_ problem with bisection is that some bugs simply cannot 
  be bisected. If it's timing-related etc, it might be a bug that comes 
  and goes, and then I'm afraid that git bisect won't really help you. ]

			Linus