Re: Feature request: Exponential search in git bisect

From: Philip Oakley <philipoakley@iee.email>
Date: Oct 26, 2020, 20:59 UTC
Message-ID: <5559c9b5-07d5-c25d-7c28-4091de34584f@iee.email>
In-Reply-To: <xmqqpn54etyp.fsf@gitster.c.googlers.com>

Hi Junio,

On 26/10/2020 18:13, Junio C Hamano wrote:

Show 17 quoted lines

> Philip Oakley <philipoakley@iee.email> writes:
>
>>> Ok, but the conclusion of the above discussion is that the problem
>>> with this idea is being able to distinguish between a commit that is
>>> bad and a commit where the feature that you want to test cannot be
>>> tested for example because it hasn't been implemented yet.
>> Does any of the proposed improvement in the "bisect: loosen halfway()
>> check for a large number of commits"
>> https://lore.kernel.org/git/20201022103806.26680-1-szeder.dev@gmail.com/
>> assist in this.
> I doubt it.  
>
> If you cannot say if a rev is testable or not, it would not help you
> much if Git asked "is this good, bad or untestable?" question 5
> times faster, I suspect.
>
>

I was more thinking along the lines, perhaps, of a narrower condition of "Too_Old" for such historical commits, rather than saying some mid-history commit just happens to be untestable in a rather indeterminate way. That would be distinctly different from the generic 'untestable' condition where a commit needs to be skipped.

It would still need an update to bisect to exponentially find the suitable start (good) zone for the real bisection.

Clearly if the user badly codes that 'Too_Old' test then they will get pulled up short, but that would be expected.

The other point was to highlight to Manuel that if the halfway check improvement was relevant to his situation then it may be that simply saying those 'Too_Old' commits were 'good' anyway, and just use the improvement it gave.