[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: git bisect enhancements?
From:       Linus Torvalds <torvalds () osdl ! org>
Date:       2005-11-30 23:32:20
Message-ID: Pine.LNX.4.64.0511301526530.3099 () g5 ! osdl ! org
[Download RAW message or body]



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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]