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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jun 28, 2015, 05:51 UTC
Message-ID: <558F8B55.1070708@alum.mit.edu>
In-Reply-To: <CAPc5daXSnovQPxR5kVoeRy4kApH7DiuTDvAz1ooQFp=5DZZg4Q@mail.gmail.com>

On 06/27/2015 06:25 AM, Junio C Hamano wrote:

Show 27 quoted lines

> On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>>
>> If we don't want to support positional arguments, then I would suggest
>> supporting first the following instead:
>>
>>          git bisect terms --name-good=fast --name-bad=slow
>>          git bisect terms --name-bad=slow --name-good=fast
>>
>> This would make the interface consistent with the code.
> 
> Which somewhat defeats the point of introducing "old" and "new", though.
> The "terms" support is for people who feel that good/bad would be too confusing
> for the particular bisect session (e.g. because they are hunting for a fix).
> 
>>> We may want to start supporting
>>>
>>>         git bisect start --new=master --old=maint
>>
>> Maybe we could also support:
>>
>> git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
> 
> The same comment for the token after --name-, but allowing the terms to be set
> at "start" could be a type-saver.  With need for added "--name-"
> prefix (worse, twice),
> I am not sure if it would be seen as a useful type-saver, though.

I would like to remind everybody of my old claim that it would be possible to teach `git bisect` to infer by itself which term means "older" and which term means "newer":

    http://article.gmane.org/gmane.comp.version-control.git/244036

I think that making `bisect` smarter could make the UI simpler, though admittedly it would be more work than the current proposal.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu