Re: git bisect enhancements?

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 30, 2005, 23:32 UTC
Message-ID: <Pine.LNX.4.64.0511301526530.3099@g5.osdl.org>
In-Reply-To: <1133386585.30767.34.camel@cashmere.sps.mot.com>

On Wed, 30 Nov 2005, Jon Loeliger wrote:

Show 9 quoted lines

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