Re: [PATCH v10.1 7/7] bisect: allow any terms set by user

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> On 06/28/2015 09:32 AM, Junio C Hamano wrote:
>> 
>> You just _always_ say "good" or "bad".  If something is slow, you
>> say "bad" and if something is fast, you say "good".
>
> Yes, I think "good" and "bad" would usually be perfectly intuitive and
> would almost always be usable.
>
>> [...]
>> No need for "bisect new", "bisect old", or "bisect terms", let alone
>> "bisect terms --new=fast --old=slow".  The tool just does the right
>> thing because it already has the information necessary to infer what
>> the user means by 'good' and 'bad', and the initial topology determines
>> which transition, either from 'good' to 'bad' or from 'bad' to 'good',
>> the user is hunting for.
>
> Correct. The only caveat is if the initial "good" and "bad" commits are
> not ancestrally related to each other. But in this case, I think
> "bisect" asks the user to test a merge base anyway, and once that one
> has been tested it will be clear which of the labels comes "before" the
> other.

The more I look at the proposal, the more I like it.  The old way of
thinking is that we need to keep 'bad' for newer one and 'good' for
older one, that required us to invent 'broken' vs 'fixed', or value
neutral 'old' vs 'new'.  Then we extend it to a random pair of
'terms', but we reserve 'good', 'bad', etc. and do not allow the
user to say "old was bad, new is now good".  With your proposal, the
user can just say "oh this is good", vs "oh this is bad".  The
mental model becomes much simpler.

I _think_ bulk of Antoine and Matthieu's work can be salvaged/reused
to implement the proposal, but now it would be more clear that
$name_good and $name_bad is a bad way to name internal variables and
files in $GIT_DIR.  The inferred 'ah you are hunting for regression'
mode would call old ones 'bad' and new ones 'good', they have to be
given value neutral names, e.g. $name_old and $name_new.