Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

Re: git-bisect failure

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:05

Possibly related (same subject, not in this thread)


On Sat, 10 Sep 2005, Andrew Morton wrote:
Junio C Hamano [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help