>>>>> On Thu, 19 Jan 2012 00:20:08 -0800, Junio C Hamano <gitster@xxxxxxxxx> said: jch> 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: jch> Just for the sake of simplicity, I'll call ff0cf12 "Q" (the Questionable jch> one). >> % git bisect start v5.15.5-159-ga71d67b v5.15.5 jch> You start by telling Git that D is bad and A is good. jch> I can see that D does contain Q (i.e. "git log D..Q" gives nothing), which jch> you should read as "D is _contaminated_ by the breakage Q introduced", so jch> D is indeed bad. jch> On the other hand, A does _not_ contain Q (i.e. "git log A..Q" gives jch> output), which you should read as "A is _not_ contaminated by the breakage jch> Q introduced", so A is indeed good. jch> 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 jch> This is your "C", and "git log C..Q" does not give anything. C is jch> 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 jch> Here, baf7658 does not contain Q, so you are supposed to answer it is jch> GOOD. >> % git bisect bad jch> But you answered that it is BAD. jch> Why? The reason turned out to be that a perl module that was involved in the testing had been upgraded in the meantime (YAML-0.77 to 0.78). So your whole answer was correctly describing the situation. From this point GiGo started to happen because the rest of the tests involved also used the newer version of that module while some other tests were done with the older version. So thank you for clearing that up! jch> [...] >>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> said: js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig: >> - A -> B -> C - D -> >> \ / >> - E - F - >> >> 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 js> I haven't looked at the actual history, but given the names of the commits js> as produced by git-describe, I doubt that your history graph sketched js> above is correct. Doesn't it look more like this: js> A -- B -- C -- D -- js> / / js> -- X -- E -- F js> where X is v5.15.4? Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58 and since there was a long timespan between the start of the development of the code and the merge (May-Nov), the gitk presentation got a bit complex to read. js> To find a commit between A and B, you must declare F as "good". Correct! The reason it happened described above. Thank you folks for taking the time and making such a careful assessment! -- andreas -- 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