Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
