Re: [RFC/PATCH]: reverse bisect v 2.0

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2011, 04:57 UTC
Message-ID: <7vr52ibydy.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAH5451kUf=vPfgOOusmJjfbiyueX9VByJLzZ9WbyqLd0z78wxA@mail.gmail.com>

Andrew Ardill <andrew.ardill@gmail.com> writes:

Show 16 quoted lines

> Examples.
> Search for a feature add:
>    $ git bisect start --introduced='feature: git frotz says xyzzy' v0.99 master
>    Bisecting: 171 revisions left to test after this (roughly 8 steps)
>    $ ... build and then test ...
>    $ git bisect tested
>    Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
> # already added, look backwards
>
> Search for a feature regression:
>    $ git bisect start --removed='feature: git frotz says xyzzy' v0.99 master
>    Bisecting: 171 revisions left to test after this (roughly 8 steps)
>    $ ... build and then test ...
>    $ git bisect tested
>    Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
> # not removed yet, look forwards

With an obvious addition of non-interactive short-cut subcommands "git bisect yes" and "git bisect no", I think --removed= is a much better wording than --used-to= I suggested in the discussion.

I however am still worried about the flipping of the mapping between <good,bad> and <yes,no> this design requires. What are we going to do to the labels of low-level machinery (i.e $GIT_DIR/refs/bisect/bad and $GIT/refs/bisect/good)? They appear in "bisect visualize" and I was hoping that it would be simpler in the code if we do not have to change them in such a way that depends on this introduced/removed switch, and that was the reason why I was trying to see if we can solve this without the switchable mapping between <good,bad> and <yes,no>.

More specifically, I was hoping that we can rename "good" to "old" and "bad" to "new" unconditionally and be done with it. We would ask the user "What did the code used to do in the olden days?" and "Does this version behave the same as it used to?". The possible answers the user can give are "git bisect old" (it behaves the same as the older versions) and "git bisect new" (it behaves the same as the newer versions). Then we do not have to worry about having to flip the meaning of <yes> and <no> at the UI level.