Re: git-bisect failure

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 10, 2005, 19:07 UTC
Message-ID: <Pine.LNX.4.58.0509101202070.30958@g5.osdl.org>
In-Reply-To: <20050910022638.20832803.akpm@osdl.org>

On Sat, 10 Sep 2005, Andrew Morton wrote:

Show 8 quoted lines

>
> Junio C Hamano <junkio@cox.net> wrote:
> >
> > So it _might_
> >  be possible that you said "current LDT" was bad when it was
> >  actually good.  That is one possible explanation.
> 
> I agree.  Mea culpa.  Sorry.

Well, this was actually something I hit when testign bisection too: it _is_ very unforgiving of mistakes.

That _may_ be something fundamental (hey, the point of bisection is that you can get a lot of work done thanks to the log2(n) behaviour, but it also means that a mistake ends up being easily multiplied). But on the other hand, maybe there could be nicer interfaces.

In particular, I suspect that we should save off the sequence of good/bad markers, so that it can be more easily re-created. Right now we only track the last "bad" marker, and we don't keep track of the order of the ones marked good. That's technically _sufficient_ for the job, but maybe we should have more of an audit trail.

With an audit trail, people could re-do the bisection if something goes wrong. Right now, if you by mistake mark something bad, and you immediately realize that it was a mistake, you can't undo it - because the old bad state was overwritten.

So the bisection algorithm may have done the right thing from a technical standpoint, but I suspect it could be made to be a bit more forgiving, or at least when somebody realizes that bisection didn't work right, we could have the trail of good/bad markings to try to debug what happened...

		Linus