git bisect enhancements?

git bisect enhancements?

[Jon Loeliger]

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

Re: git bisect enhancements?

[Junio C Hamano]

Jon Loeliger <jdl@freescale.com> writes:

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

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?

Re: git bisect enhancements?

[Jon Loeliger]

On Wed, 2005-11-30 at 16:04, Junio C Hamano wrote:
> Jon Loeliger <jdl@freescale.com> writes:
> 
> > ...  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.
> 
> 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?

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

Re: git bisect enhancements?

[Junio C Hamano]

Jon Loeliger <jdl@freescale.com> writes:

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

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.

Re: git bisect enhancements?

[Junio C Hamano]

Jon Loeliger <jdl@freescale.com> writes:

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

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.

Re: git bisect enhancements?

[Linus Torvalds]

On Wed, 30 Nov 2005, Jon Loeliger wrote:
> 
> 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?

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