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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 28, 2015, 11:31 UTC
Message-ID: <558FDAF9.3010300@alum.mit.edu>
In-Reply-To: <xmqqwpyoe1aj.fsf@gitster.dls.corp.google.com>

On 06/28/2015 09:32 AM, Junio C Hamano wrote:

Show 22 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> I understand that the user might make a mistake when marking the initial
>> commits, but as soon as bisect says
>>
>>     Commit <sha1-abbrev> is an ancestor of <sha1-abbrev>, so I
>>     will look for the commit that caused the transition from
>>     "xyzzy" to "plugh".
>>
>> then I hope the user will notice and correct her/his mistake.
>>
>> For example, a session could be started with
>>
>>     git bisect start --mark=broken <committish> --mark=fixed <committish>
> 
> Interesting.
> 
> If we extend that line of thought further, maybe we do not even need
> to add new/old, fixed/broken, or slow/fast.
> 
> 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.

Show 7 quoted lines

> [...]
> 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.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu