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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2008, 22:30 UTC
Message-ID: <7vej6mbh3w.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080624174157.GB9500@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> On Tue, Jun 24, 2008 at 06:09:28PM +0100, Johannes Schindelin wrote:
>
>> 	And this is my first attempt at a proper patch for it.
>> 
>> 	Now with documentation, and hopefully all places where the
>> 	user is being told about a "bad" commit.
>
> This looks reasonably sane to me. The only thing I can think of that
> we're missing is that "git bisect visualize" will still show the refs as
> "bisect/bad" and "bisect/good".
>
> To fix that, you'd have to ask people to start the bisect by saying "I
> am bisecting to find a fix, not a breakage." And then you could change
> the refnames and all of the messages as appropriate.

It probably is not just a good idea, but is a necessary fix, to remove confusion like this example that appears everywhere:

Show 5 quoted lines

>  		echo >&2 'You '$THEN'need to give me at least one good' \
> -			'and one bad revisions.'
> +			'and one bad (or fixed) revision.'
>  		echo >&2 '(You can use "git bisect bad" and' \
>  			'"git bisect good" for that.)'

People who are reading the change Dscho did in the "patch" form may not notice it, but imagine how the above looks to the end user who was told that "new bisect can now look for fixes", who does not need to nor even want to know that the new feature is implemented by making bad and fixed synonyms.

They need to mentally reword "good" into "unfixed" and "bisect bad" into "bisect fixed" while reading the output from the above pieces, but the point of this new "look for fixes" feature is they do not have to do the rewording anymore!