Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2008, 22:31 UTC
Message-ID: <7v8wwubh3j.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0806242137120.9925@racer>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

> On Tue, 24 Jun 2008, Michael Haggerty wrote:
> ...
>> It seems to me that your problem is that git-bisect requires the "good" 
>> revision to be older than the "bad" one.  If this requirement were 
>> removed, would there still be a need for "fixed" vs. "unfixed"?
>
> Nope.
>
> The thing that makes "fixed" and "bad" special is that _one_ commit 
> introduced that.

That was my initial reaction, and I actually was about to phrase it more bluntly: you do not understand what "bisect" is.

But that was a reaction without thinking things through. It may not be what "git bisect" currently is, but the suggestion does not go against what the underlying "git rev-list --bisect" is at all. I think what Michael is speculating is different, and it makes sense in its own way.

Instead of having a set of bisect/good-* refs and a single bisect-bad ref, your "fixed and unfixed" mode could work quite differently. By noticing that the topology the user specified with initial good and bad have ancient bad and recent good --- that is, "it used to be bad but now it is good" --- you could instead use a set of bisect/bad-* refs and a single bisect-good ref, and feed good and bad swapped to "rev-list --bisect" in bisect_next(). That way, the labels given by visualize will match what the user is doing automatically.

I said "it makes sense in its own way", because it is _quite_ different from how git-bisect currently assumes, and restructuring git-bisect to operate naturally in a way Michael describes would be a much larger surgery with costs (including risks of bugs) associated with it, which needs to be weighed in when judging that approach would actually make sense.