{"thread":{"id":"29398","subject":"[BUG] Git bisect not finding the right commit","startedAt":"2012-01-19T03:29:49Z","lastAt":"2012-01-24T20:21:54Z","messageCount":6,"participants":["Andreas J. Koenig","Junio C Hamano","Johannes Sixt","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182765","messageId":"87r4yw8j4i.fsf@franz.ak.mind.de","threadId":"29398","inReplyTo":null,"subject":"[BUG] Git bisect not finding the right commit","fromName":"Andreas J. Koenig","fromEmail":"andreas.koenig.7os6vvqr@franz.ak.mind.de","sentAt":"2012-01-19T03:29:49Z","receivedAt":"2012-01-19T03:29:49Z","isPatch":false,"sender":{"key":"andreas.koenig.7os6vvqr@franz.ak.mind.de","avatar":null},"body":"My git versions\n---------------\n1.7.9.rc2 and 1.7.8.3 and 1.7.2.5\n\nThe example output below was produced with 1.7.8.3 as provided by debian\n\"git/unstable uptodate 1:1.7.8.3-1\"\n\nThe result looks the same on all three versions. I did not do a\nbyte-by-byte comparison, but the outcome is the same.\n\nThe repository\n--------------\nhttp://perl5.git.perl.org/perl.git\n\nProblem description\n-------------------\nAfter v5.15.5-20-gfd76d40 a merge happened and v5.15.4-110-g27b29ec\nthrough v5.15.4-169-g3582575 were inserted. The code was developed\nbefore v5.15.5 but merged after v5.15.5.\n\n\t- A -> B      ->     C - D ->\n\t         \\         /\n\t          - E - F -\n\nA v5.15.5\nB v5.15.5-20-gfd76d40\nC v5.15.5-81-gcfe287a\nD v5.15.5-159-ga71d67b\nE v5.15.4-110-g27b29ec\nF v5.15.4-169-g3582575\n\nThe change in perl I tried to locate was v5.15.5-13-gff0cf12, between A\nand B. Bisect did not find it, it returned me E instead. Here the wrong\nbisect output:\n\n% git bisect start v5.15.5-159-ga71d67b v5.15.5\nAlready on 'blead'\nBisecting: 77 revisions left to test after this (roughly 6 steps)\n[cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead\n% git describe\nv5.15.5-81-gcfe287a\n% git bisect bad\nBisecting: 40 revisions left to test after this (roughly 5 steps)\n[baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html\n% git describe\nv5.15.4-149-gbaf7658\n% git bisect bad\nBisecting: 19 revisions left to test after this (roughly 4 steps)\n[fbf24e084f7e43d3caa066f3520b4c32ebbb2e3a] Start modifying test cases to suit new Pod::Html\n% git describe\nv5.15.4-129-gfbf24e0\n% git bisect bad\nBisecting: 9 revisions left to test after this (roughly 3 steps)\n[9949917516c8bca1036187e3e878ed8869558a65] Finish skeleton version of Pod::Html\n% git describe\nv5.15.4-119-g9949917\n% git bisect bad\nBisecting: 4 revisions left to test after this (roughly 2 steps)\n[953c3c52c300d440cb8e0811a812e78c12d45695] Remove spurious code after start of parser switch\n% git describe\nv5.15.4-114-g953c3c5\n% git bisect bad\nBisecting: 2 revisions left to test after this (roughly 1 step)\n[2618a74b5307cde59d3b3111031637fbe4bfe0cf] Remove cache feature for simplicity\n% git describe\nv5.15.4-111-g2618a74\n% git bisect bad\nBisecting: 0 revisions left to test after this (roughly 0 steps)\n[27b29ec338b08496d21538c0db7377d446529f8b] Remove deprecated --netscape flag\n% git describe\nv5.15.4-110-g27b29ec\n% git bisect bad\n27b29ec338b08496d21538c0db7377d446529f8b is the first bad commit\ncommit 27b29ec338b08496d21538c0db7377d446529f8b\nAuthor: Marc Green <marcgreen@cpan.org>\nDate:   Mon May 16 23:46:07 2011 -0400\n\n deprecated --netscape flag\n\n:040000 040000 6759c516ef91450c73a01c5695051f31b787171e 080d58438a5c00aaaa6464f4c3a42c2ffd5f7ee0 M      ext\n% git version\ngit version 1.7.8.3\n\n\nWhat I expected\n---------------\nThe above result is wrong, git should have found v5.15.5-13-gff0cf12.\nGit seemingly did not consider the revisions between v5.15.5 and\nv5.15.5-20-gfd76d40.\n\nLet me know if you need further informations. (I'm not subscribed to the\nmailing list.)\n\nThanks && Regards,\n-- \nandreas\n"},{"id":"182768","messageId":"7vlip4je87.fsf@alter.siamese.dyndns.org","threadId":"29398","inReplyTo":"87r4yw8j4i.fsf@franz.ak.mind.de","subject":"Re: [BUG] Git bisect not finding the right commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-19T08:20:08Z","receivedAt":"2012-01-19T08:20:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:\n\n> A v5.15.5\n> B v5.15.5-20-gfd76d40\n> C v5.15.5-81-gcfe287a\n> D v5.15.5-159-ga71d67b\n> E v5.15.4-110-g27b29ec\n> F v5.15.4-169-g3582575\n>\n> The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A\n> and B. Bisect did not find it, it returned me E instead. Here the wrong\n> bisect output:\n\nJust for the sake of simplicity, I'll call ff0cf12 \"Q\" (the Questionable\none).\n\n> % git bisect start v5.15.5-159-ga71d67b v5.15.5\n\nYou start by telling Git that D is bad and A is good.\n\nI can see that D does contain Q (i.e. \"git log D..Q\" gives nothing), which\nyou should read as \"D is _contaminated_ by the breakage Q introduced\", so\nD is indeed bad.\n\nOn the other hand, A does _not_ contain Q (i.e. \"git log A..Q\" gives\noutput), which you should read as \"A is _not_ contaminated by the breakage\nQ introduced\", so A is indeed good.\n\nSo far so good...\n\n> Already on 'blead'\n> Bisecting: 77 revisions left to test after this (roughly 6 steps)\n> [cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead\n> % git describe\n> v5.15.5-81-gcfe287a\n\nThis is your \"C\", and \"git log C..Q\" does not give anything. C is\ncontaminated by Q, hence it is bad.\n\n> % git bisect bad\n> Bisecting: 40 revisions left to test after this (roughly 5 steps)\n> [baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html\n> % git describe\n> v5.15.4-149-gbaf7658\n\nHere, baf7658 does not contain Q, so you are supposed to answer it is\nGOOD.\n\n> % git bisect bad\n\nBut you answered that it is BAD.\n\nWhy?\n\nWhat caused you to say \"bad\" here to a commit that could not possibly have\ninherited the breakage Q introduced?\n\nOne plausible explanation is that whatever symptom you are seeing in Perl\nat version Q that you call \"bad\" may not be caused by a single root cause,\nand a similar (or the same) symptom somehow appears at this version that\nis _NOT_ contaminated by Q.\n\nAnother plausible scenario is that the symptom you are chasing may not be\nreliably reproducible.\n\n\"bisection\" by nature is an optimization technique applicable only when\nyou are chasing a reliably reproducible symptom that is caused by a single\ncause, a breakage that existed in a single old version that is inherited\nto all its descendants, and the \"bad\" symptom did not appear in any\nversion that does not inherit the breakage from that single problematic\ncommit.  If you have a history A--B--C--D--E, in which B breaks something,\nC fixes its breakage and then D reintroduces another breakage that shows\nthe same symptom, you can not optimize the search for a problem using\nbisect. You need to check each and every version.\n\nOf course, people sometimes simply get confused and mistakenly say BAD\nwhen they wanted to say GOOD. That may be a simpler explanation of what\nhappened to your bisection.\n\nAnyway, the remainder of your bisect sequence is GiGo, so I'll snip them\nand will not quote.\n"},{"id":"182769","messageId":"4F17D2E5.7000400@viscovery.net","threadId":"29398","inReplyTo":"87r4yw8j4i.fsf@franz.ak.mind.de","subject":"Re: [BUG] Git bisect not finding the right commit","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-01-19T08:23:01Z","receivedAt":"2012-01-19T08:23:01Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 1/19/2012 4:29, schrieb Andreas J. Koenig:\n> \t- A -> B      ->     C - D ->\n> \t         \\         /\n> \t          - E - F -\n> \n> A v5.15.5\n> B v5.15.5-20-gfd76d40\n> C v5.15.5-81-gcfe287a\n> D v5.15.5-159-ga71d67b\n> E v5.15.4-110-g27b29ec\n> F v5.15.4-169-g3582575\n\nI haven't looked at the actual history, but given the names of the commits\nas produced by git-describe, I doubt that your history graph sketched\nabove is correct. Doesn't it look more like this:\n\n      A -- B -- C -- D --\n     /         /\n -- X -- E -- F\n\nwhere X is v5.15.4?\n\nTo find a commit between A and B, you must declare F as \"good\".\n\n-- Hannes\n"},{"id":"182844","messageId":"87ehuu958d.fsf@franz.ak.mind.de","threadId":"29398","inReplyTo":"7vlip4je87.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Git bisect not finding the right commit","fromName":"Andreas J. Koenig","fromEmail":"andreas.koenig.7os6vvqr@franz.ak.mind.de","sentAt":"2012-01-20T07:56:50Z","receivedAt":"2012-01-20T07:56:50Z","isPatch":false,"sender":{"key":"andreas.koenig.7os6vvqr@franz.ak.mind.de","avatar":null},"body":">>>>> On Thu, 19 Jan 2012 00:20:08 -0800, Junio C Hamano <gitster@pobox.com> said:\n\n jch> andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:\n >> A v5.15.5\n >> B v5.15.5-20-gfd76d40\n >> C v5.15.5-81-gcfe287a\n >> D v5.15.5-159-ga71d67b\n >> E v5.15.4-110-g27b29ec\n >> F v5.15.4-169-g3582575\n >> \n >> The change in perl I tried to locate was v5.15.5-13-gff0cf12, between A\n >> and B. Bisect did not find it, it returned me E instead. Here the wrong\n >> bisect output:\n\n jch> Just for the sake of simplicity, I'll call ff0cf12 \"Q\" (the Questionable\n jch> one).\n\n >> % git bisect start v5.15.5-159-ga71d67b v5.15.5\n\n jch> You start by telling Git that D is bad and A is good.\n\n jch> I can see that D does contain Q (i.e. \"git log D..Q\" gives nothing), which\n jch> you should read as \"D is _contaminated_ by the breakage Q introduced\", so\n jch> D is indeed bad.\n\n jch> On the other hand, A does _not_ contain Q (i.e. \"git log A..Q\" gives\n jch> output), which you should read as \"A is _not_ contaminated by the breakage\n jch> Q introduced\", so A is indeed good.\n\n jch> So far so good...\n\n >> Already on 'blead'\n >> Bisecting: 77 revisions left to test after this (roughly 6 steps)\n >> [cfe287a06b2ed98c25aebb477f6b400409f1fc85] Merge remote-tracking branch 'p5p/smoke-me/gsoc-pod' into blead\n >> % git describe\n >> v5.15.5-81-gcfe287a\n\n jch> This is your \"C\", and \"git log C..Q\" does not give anything. C is\n jch> contaminated by Q, hence it is bad.\n\n >> % git bisect bad\n >> Bisecting: 40 revisions left to test after this (roughly 5 steps)\n >> [baf7658bacfa659cdab08050470b20ebd5973384] Update htmlview.t for new Pod::Html\n >> % git describe\n >> v5.15.4-149-gbaf7658\n\n jch> Here, baf7658 does not contain Q, so you are supposed to answer it is\n jch> GOOD.\n\n >> % git bisect bad\n\n jch> But you answered that it is BAD.\n\n jch> Why?\n\nThe reason turned out to be that a perl module that was involved in the\ntesting had been upgraded in the meantime (YAML-0.77 to 0.78). So your\nwhole answer was correctly describing the situation. From this point\nGiGo started to happen because the rest of the tests involved also used\nthe newer version of that module while some other tests were done with\nthe older version.\n\nSo thank you for clearing that up!\n\n jch> [...]\n\n>>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@viscovery.net> said:\n\n js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig:\n >> - A -> B      ->     C - D ->\n >>          \\         /\n >>           - E - F -\n >> \n >> A v5.15.5\n >> B v5.15.5-20-gfd76d40\n >> C v5.15.5-81-gcfe287a\n >> D v5.15.5-159-ga71d67b\n >> E v5.15.4-110-g27b29ec\n >> F v5.15.4-169-g3582575\n\n js> I haven't looked at the actual history, but given the names of the commits\n js> as produced by git-describe, I doubt that your history graph sketched\n js> above is correct. Doesn't it look more like this:\n\n js>       A -- B -- C -- D --\n js>      /         /\n js>  -- X -- E -- F\n\n js> where X is v5.15.4?\n\nYes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58\nand since there was a long timespan between the start of the development\nof the code and the merge (May-Nov), the gitk presentation got a bit\ncomplex to read.\n\n js> To find a commit between A and B, you must declare F as \"good\".\n\nCorrect! The reason it happened described above.\n\nThank you folks for taking the time and making such a careful assessment!\n-- \nandreas\n"},{"id":"182864","messageId":"7vk44mfdow.fsf@alter.siamese.dyndns.org","threadId":"29398","inReplyTo":"87ehuu958d.fsf@franz.ak.mind.de","subject":"Re: [BUG] Git bisect not finding the right commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-20T18:09:51Z","receivedAt":"2012-01-20T18:09:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"andreas.koenig.7os6VVqR@franz.ak.mind.de (Andreas J. Koenig) writes:\n\n>>>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@viscovery.net> said:\n>\n>  js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig:\n>  >> - A -> B      ->     C - D ->\n>  >>          \\         /\n>  >>           - E - F -\n>  >> \n>  >> A v5.15.5\n>  >> B v5.15.5-20-gfd76d40\n>  >> C v5.15.5-81-gcfe287a\n>  >> D v5.15.5-159-ga71d67b\n>  >> E v5.15.4-110-g27b29ec\n>  >> F v5.15.4-169-g3582575\n>\n>  js> I haven't looked at the actual history, but given the names of the commits\n>  js> as produced by git-describe, I doubt that your history graph sketched\n>  js> above is correct. Doesn't it look more like this:\n>\n>  js>       A -- B -- C -- D --\n>  js>      /         /\n>  js>  -- X -- E -- F\n>\n>  js> where X is v5.15.4?\n>\n> Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58\n> and since there was a long timespan between the start of the development\n> of the code and the merge (May-Nov), the gitk presentation got a bit\n> complex to read.\n\n(This is somewhat off-topic, so Andreas is on Cc: and the list is on To:)\n\nI doubt --simplify-by-decoration alone would make it easier to view such a\ncomplex and long history, but I wonder if we can use the same logic to\nhelp users in a case like this. Instead of only keeping tagged versions in\nthe result to show topology, perhaps we can allow the user to feed a list\nof \"key points in history\" as command line arguments and apply the same\nkind of simplification to help visualizing the topology?\n"},{"id":"183036","messageId":"20120124202154.GB20145@sigill.intra.peff.net","threadId":"29398","inReplyTo":"7vk44mfdow.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Git bisect not finding the right commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-24T20:21:54Z","receivedAt":"2012-01-24T20:21:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 20, 2012 at 10:09:51AM -0800, Junio C Hamano wrote:\n\n> > Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58\n> > and since there was a long timespan between the start of the development\n> > of the code and the merge (May-Nov), the gitk presentation got a bit\n> > complex to read.\n> \n> (This is somewhat off-topic, so Andreas is on Cc: and the list is on To:)\n> \n> I doubt --simplify-by-decoration alone would make it easier to view such a\n> complex and long history, but I wonder if we can use the same logic to\n> help users in a case like this. Instead of only keeping tagged versions in\n> the result to show topology, perhaps we can allow the user to feed a list\n> of \"key points in history\" as command line arguments and apply the same\n> kind of simplification to help visualizing the topology?\n\nThis is something I think I've wanted in the past. But unfortunately, I\ncan't remember the exact details, so I'm not sure how workable it would\nhave been. In particular, how painful is it in practice to come up with\nthe list of \"key points\" to make the graph sensible?\n\nSo I'll add my vague \"yeah, that sounds good\" and try to pay attention\nnext time the situation comes up as to whether such a feature would\nactually help in practice.\n\n-Peff\n"}]}