Re: git bisect for reachable commits only

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2016, 19:51 UTC
Message-ID: <xmqq7fc0jmhx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAP8UFD118RdB5dX2-wEm5VnKud7sirHhdC9kvWmXV0eAQHvfsA@mail.gmail.com>

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

Show 6 quoted lines

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

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

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.

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.