Comment 1 for bug 1051395

Originally, the meaning of "yes" and "no" was intended to be dependent on how you used it. If you started out with "yes" meaning the same as git's "good", it would honor that; if you started with "no" meaning "good", it would do that too.

The reason: I didn't like the "good" vs. "bad" naming in git. If you were trying to find a fix or new feature, say, instead of a regression, then you'd be saying the feature was bad. My thought was: create a question that can be answered "yes" or "no", and answer it for each revision. As long as the question was the same, it should work.

Unfortunately, I never wrote a test for this, and the functionality bit-rotted (if it ever worked to begin with).

I've posted a branch which fixes this, as well as a functional test for the feature. With this branch, this:

bzr bisect start
bzr bisect yes
bzr bisect no -r -3

and:

bzr bisect start
bzr bisect no
bzr bisect yes -r -3

should be exactly equivalent.

I'll propose my branch for merging. Assuming this works, does it resolve the confusion you had?