andreas.koenig.7os6VVqR@xxxxxxxxxxxxxxxx (Andreas J. Koenig) writes: > A v5.15.5 > B v5.15.5-20-gfd76d40 > C v5.15.5-81-gcfe287a > D v5.15.5-159-ga71d67b > E v5.15.4-110-g27b29ec > F v5.15.4-169-g3582575 > > The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A > and B. Bisect did not find it, it returned me E instead. Here the wrong > bisect output: Just for the sake of simplicity, I'll call ff0cf12 "Q" (the Questionable one). > % git bisect start v5.15.5-159-ga71d67b v5.15.5 You start by telling Git that D is bad and A is good. I can see that D does contain Q (i.e. "git log D..Q" gives nothing), which you should read as "D is _contaminated_ by the breakage Q introduced", so D is indeed bad. On the other hand, A does _not_ contain Q (i.e. "git log A..Q" gives output), which you should read as "A is _not_ contaminated by the breakage Q introduced", so A is indeed good. So far so good... > Already on 'blead' > Bisecting: 77 revisions left to test after this (roughly 6 steps) > [cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead > % git describe > v5.15.5-81-gcfe287a This is your "C", and "git log C..Q" does not give anything. C is contaminated by Q, hence it is bad. > % git bisect bad > Bisecting: 40 revisions left to test after this (roughly 5 steps) > [baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html > % git describe > v5.15.4-149-gbaf7658 Here, baf7658 does not contain Q, so you are supposed to answer it is GOOD. > % git bisect bad But you answered that it is BAD. Why? What caused you to say "bad" here to a commit that could not possibly have inherited the breakage Q introduced? One plausible explanation is that whatever symptom you are seeing in Perl at version Q that you call "bad" may not be caused by a single root cause, and a similar (or the same) symptom somehow appears at this version that is _NOT_ contaminated by Q. Another plausible scenario is that the symptom you are chasing may not be reliably reproducible. "bisection" by nature is an optimization technique applicable only when you are chasing a reliably reproducible symptom that is caused by a single cause, a breakage that existed in a single old version that is inherited to all its descendants, and the "bad" symptom did not appear in any version that does not inherit the breakage from that single problematic commit. If you have a history A--B--C--D--E, in which B breaks something, C fixes its breakage and then D reintroduces another breakage that shows the same symptom, you can not optimize the search for a problem using bisect. You need to check each and every version. Of course, people sometimes simply get confused and mistakenly say BAD when they wanted to say GOOD. That may be a simpler explanation of what happened to your bisection. Anyway, the remainder of your bisect sequence is GiGo, so I'll snip them and will not quote. -- 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