Re: [PUB]What's cooking in git.git (Aug 2015, #05; Fri, 28)

From: Christian Couder <christian.couder@gmail.com>
Date: Aug 31, 2015, 07:48 UTC
Message-ID: <CAP8UFD0LsjPz-Ap7_eQMUmdkePOv=mn6Q-asuJbtPme5uT5GYA@mail.gmail.com>
In-Reply-To: <vpqzj17hpt8.fsf@anie.imag.fr>

On Mon, Aug 31, 2015 at 9:36 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 25 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> * ad/bisect-terms (2015-08-03) 4 commits
>>  - bisect: allow setting any user-specified in 'git bisect start'
>>  - bisect: add 'git bisect terms' to view the current terms
>>  - bisect: add the terms old/new
>>  - bisect: sanity check on terms
>>
>>  The use of 'good/bad' in "git bisect" made it confusing to use when
>>  hunting for a state change that is not a regression (e.g. bugfix).
>>  The command learned 'old/new' and then allows the end user to
>>  say e.g. "bisect start --term-old=fast --term=new=slow" to find a
>>  performance regression.
>>
>>  Michael's idea to make 'good/bad' more intelligent does have
>>  certain attractiveness ($gname/272867), and makes some of the work
>>  on this topic a moot point.
>>
>>  Will hold.
>
> This topic has been there for a while and unless I missed a discussion,
> nothing happened. While I agree that Michael's idea is good and makes
> this series less useful, I think this topic also makes sense.
>
> I'd be in favor of merging it.

My opinion on this is that Michael's idea, even if it is good, is not compatible with the current way bisect works, so, if it is ever implemented, it will probably need a special flag like "git start --possibly-find-fix".

That's why I'd also be in favor of merging this series.