Junio C Hamano <gitster@xxxxxxxxx> writes: > Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > >> Le mardi 1 juillet 2008, Junio C Hamano a écrit : >>> Christian Couder <chriscool@xxxxxxxxxxxxx> writes: >>> > Before this patch "git bisect" doesn't really work when it is given >>> > some good revs that are siblings of the bad rev. >>> > >>> > For example if there is the following history: >>> > >>> > A-B-C-D >>> > \E-F >>> > >>> > and we launch "git bisect start D F" then only C and D will be >>> > considered as possible first bad commit. >> >> I am assuming the first bad commit in the graph is A and it is fixed by F. > > Ah, I see your confusion here. bisect is about finding regressions. > "Older ones were good, and now there is a breakage. Who broke it?" > > If F fixed it, that is already outside the bisection's scope. The user > needs to know that by saying F is good, he is saying he knows everything > that leads to F is good. Ok, I wasn't thinking straight. The tricky part is that the user does not know. Until we somehow can check B is bad, we cannot tell that the original bisection was done incorrectly (in the sense that it was not finding regression, but what the user could find is which commit fixed it). If we perform a test merge between D and F and test that tree, and if that turns out to be Ok, that would be a good indication of existence of a fix (i.e. the topology is not "old good code was broken somewhere", but "old broken code was fixed somewhere"). I am not sure how applicable that approach would be in practice, though. -- 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
