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