Re: git bisect for reachable commits only

From: Christian Couder <christian.couder@gmail.com>
Date: Aug 1, 2016, 20:36 UTC
Message-ID: <CAP8UFD315CgntwYiC9g-R7KN0XiL9635Vwv_y8yi4n-uj8o90A@mail.gmail.com>
In-Reply-To: <xmqq7fc0jmhx.fsf@gitster.mtv.corp.google.com>

On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Christian Couder <christian.couder@gmail.com> writes:
>
>> Yes, and the reason is that all the ancestors of a good commit are
>> considered good.
>> That's because git bisect supposes that there is only one transition
>> from good to bad.
>> Otherwise we would need a more complex algorithm to find all the
>> transitions from good to bad, and that is not generally needed.
>
> It may be debatable if that is generally needed or not, but by
> definition "bisect" is about having a history that has a SINGLE
> point that changes from good to bad (or old to new, or "have sugar"
> to "no sugar"), and that single-ness is what allows us to BIsect the
> graph.  So even if it may be a good thing to have to be able to find
> multiple transitions, that is outside the scope of how the current
> "git bisect" was designed to be used.

Yeah, this is a better version of what I wanted to say.

Show 12 quoted lines

>> I haven't looked at your previous issue much, sorry I have been busy these days.
>
> I think the "previous issue" was that we can ask the user to ask to
> check one of 'x' or 'y' when given Good and Bad points in a graph like
> this:
>
>         x---y---y---o---B
>          \         /
>           x---G---o
>
> while a more natural expectation by a user would be that we only
> need to check one of these two 'o'.

Yeah, I reproduced the steps described in the Google Groups discussion:

https://groups.google.com/forum/#!topic/git-users/v3__t42qbKE

and I think that is indeed the "previous issue".

Show 6 quoted lines

> Thinking about it again, I actually think it makes sense to ask the
> user to check 'y'; there is no good reason to believe that 'y' can
> never have introduced the badness we are hunting for, and limiting
> the search to --ancestry-path (which is to ask only for 'o') would
> stop at the merge 'o' if one of the 'y' were bad, which would
> prevents us from knowing the exact breakage.

I agree.

> There however is no excuse if we asked to check 'x', though.  They
> are ancestors of a Good commit, and "git bisect" should be able to
> assume they are Good.

I think it does. When I reproduced the steps in the "previous issue", it did assume they are good.