On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Christian Couder <christian.couder@xxxxxxxxx> 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. >> 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". > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html