From: Jon Loeliger <jdl@freescale.com>
Date: Wed, 30 Nov 2005 21:36:26 GMT
Subject: git bisect enhancements?
Message-ID: <1133386585.30767.34.camel@cashmere.sps.mot.com>

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