Re: git bisect for reachable commits only

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2016, 23:11 UTC
Message-ID: <xmqqwpk0f5jr.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAP8UFD315CgntwYiC9g-R7KN0XiL9635Vwv_y8yi4n-uj8o90A@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 25 quoted lines

>> 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".
>
>> 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.

Having agreed on that, there are cases where you do want to stop at the merge 'o' on the upper history, when lower-history leading to B is the mainline and you are interested in finding the merge with which side branch introduced a breakage, and not particularly interested in finding the exact commit on the side branch. Upon finding the merge 'o' that is the parent of 'B' is bad, you find out the owner of the side branch merged there who wrote the two 'y's, and have him work on figuring out where in his branch he broke it.

For that, the --ancestry-path is a wrong way to traverse; what we want in that context is the --first-parent traversal.

Show 6 quoted lines

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

I actually had an impression that the original report claimed that the user was asked to check immediate parent of G, and that would be a bug.