{"thread":{"id":"26888","subject":"Why can't I use git-bisect to find the first *good* commit?","startedAt":"2011-03-28T09:32:21Z","lastAt":"2011-05-22T19:41:07Z","messageCount":23,"participants":["Ævar Arnfjörð Bjarmason","Andreas Ericsson","code.sculptor@gmail.com","Vincent van Ravesteijn","Matthieu Moy","Christian Couder","Andrew Garber","Johannes Sixt","demerphq","Jeff King","Michael Witten"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"164418","messageId":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","threadId":"26888","inReplyTo":null,"subject":"Why can't I use git-bisect to find the first *good* commit?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-03-28T09:32:21Z","receivedAt":"2011-03-28T09:32:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Something was broken a 100 revisions ago, has now been fixed, but I\nwant to find when it was fixed.\n\nI'd expect this to work:\n\n $ git bisect start\n $ git bisect good\n $ git bisect bad HEAD~100\n Some good revs are not ancestor of the bad rev.\n git bisect cannot work properly in this case.\n Maybe you mistake good and bad revs?\n\nBut instead I have to do:\n\n $ git bisect start\n $ git bisect bad\n $ git bisect good HEAD~100\n\nAnd then proceed to mark good revisions as bad, and bad revisions as\ngood.\n\nThat works, but it's very confusing.\n\nWhy can't bisect just do the right thing here and accept that your\nmore recent revesion is the good one, and the old one is the bad one?\n"},{"id":"164419","messageId":"4D906549.9050102@op5.se","threadId":"26888","inReplyTo":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-03-28T10:39:05Z","receivedAt":"2011-03-28T10:39:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 03/28/2011 11:32 AM, Ævar Arnfjörð Bjarmason wrote:\n> Something was broken a 100 revisions ago, has now been fixed, but I\n> want to find when it was fixed.\n> \n> I'd expect this to work:\n> \n> $ git bisect start\n> $ git bisect good\n> $ git bisect bad HEAD~100\n> Some good revs are not ancestor of the bad rev.\n> git bisect cannot work properly in this case.\n> Maybe you mistake good and bad revs?\n> \n> But instead I have to do:\n> \n> $ git bisect start\n> $ git bisect bad\n> $ git bisect good HEAD~100\n> \n> And then proceed to mark good revisions as bad, and bad revisions as\n> good.\n> \n> That works, but it's very confusing.\n> \n> Why can't bisect just do the right thing here and accept that your\n> more recent revesion is the good one, and the old one is the bad one?\n\nIt's due to the fact that bisect is, in 99% of the cases, used to\nlocate the commit that introduced a bug and the implementation details\nnaturally gear towards that scenario, with fixed names that do the\nRight Thing(tm) in 99% of all cases.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"164426","messageId":"1871454323-1301314947-cardhu_decombobulator_blackberry.rim.net-1749053087-@bda570.bisx.prod.on.blackberry","threadId":"26888","inReplyTo":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"","fromEmail":"code.sculptor@gmail.com","sentAt":"2011-03-28T12:22:32Z","receivedAt":"2011-03-28T12:22:32Z","isPatch":false,"sender":{"key":"code.sculptor@gmail.com","avatar":null},"body":"That's a really good point! Perhaps we should have a --invert flag?\nSent from my BlackBerry device on the Rogers Wireless Network\n\n-----Original Message-----\nFrom: Ævar Arnfjörð Bjarmason \nSender: git-owner@vger.kernel.org\nDate: Mon, 28 Mar 2011 11:32:21 \nTo: Git Mailing List\nSubject: Why can't I use git-bisect to find the first *good* commit?\n\nSomething was broken a 100 revisions ago, has now been fixed, but I\nwant to find when it was fixed.\n\nI'd expect this to work:\n\n $ git bisect start\n $ git bisect good\n $ git bisect bad HEAD~100\n Some good revs are not ancestor of the bad rev.\n git bisect cannot work properly in this case.\n Maybe you mistake good and bad revs?\n\nBut instead I have to do:\n\n $ git bisect start\n $ git bisect bad\n $ git bisect good HEAD~100\n\nAnd then proceed to mark good revisions as bad, and bad revisions as\ngood.\n\nThat works, but it's very confusing.\n\nWhy can't bisect just do the right thing here and accept that your\nmore recent revesion is the good one, and the old one is the bad one?\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in\nthe body of a message to majordomo@vger.kernel.org\nMore majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"164427","messageId":"4D908170.2020207@lyx.org","threadId":"26888","inReplyTo":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2011-03-28T12:39:12Z","receivedAt":"2011-03-28T12:39:12Z","isPatch":false,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"\n> Why can't bisect just do the right thing here and accept that your\n> more recent revesion is the good one, and the old one is the bad one?\n\nThere was a recent discussion about this:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/165433\n\nVincent\n"},{"id":"164428","messageId":"vpqy63ztnae.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"1871454323-1301314947-cardhu_decombobulator_blackberry.rim.net-1749053087-@bda570.bisx.prod.on.blackberry","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T12:58:01Z","receivedAt":"2011-03-28T12:58:01Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"code.sculptor@gmail.com writes:\n\n> That's a really good point! Perhaps we should have a --invert flag?\n\nIIRC, bzr uses \"yes\" and \"no\" instead of \"good\" and \"bad\" for this\nreason: \"yes/no the code works\" or \"yes/no the code is broken\" depending\non what you're looking for.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164434","messageId":"AANLkTikcQJjwFtsWhr+75vcZbwVxFVzqMttHX1Rz0rw7@mail.gmail.com","threadId":"26888","inReplyTo":"4D908170.2020207@lyx.org","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2011-03-28T14:04:47Z","receivedAt":"2011-03-28T14:04:47Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 28, 2011 at 2:39 PM, Vincent van Ravesteijn wrote:\n>\n>> Why can't bisect just do the right thing here and accept that your\n>> more recent revesion is the good one, and the old one is the bad one?\n>\n> There was a recent discussion about this:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/165433\n\nThe recent discussion about this topic is rather this one:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/165141\n\nand it refers to this one that started with Dscho's patch:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/86063\n\nThanks,\nChristian.\n"},{"id":"164436","messageId":"AANLkTin1QCda9BV+gND1kcXRTZBF7hj3Chce5OkLX2a9@mail.gmail.com","threadId":"26888","inReplyTo":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T14:29:38Z","receivedAt":"2011-03-28T14:29:38Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":"> I'd expect this to work:\n>\n>    $ git bisect start\n>    $ git bisect good\n>    $ git bisect bad HEAD~100\n\nSo would I. I think the behavior of git bisect should be changed.\nRight now, it's trying to find the first bad commit. Instead, it\nshould be trying to find the first commit where the code's good/bad\nstate *changed*. IOW, it should be able to handle both of the\nfollowing cases:\n\ngood <--- oldest\ngood\ngood\nbad <--- the commit we want bisect to find\nbad\nbad <--- newest\n\nbad <--- oldest\nbad\nbad\ngood <--- the commit we want bisect to find\ngood\ngood <--- newest\n\nIt shouldn't matter which end we start on, so long as one end gets\nmarks good, and the other end gets marked bad.\n\nAndrew\n"},{"id":"164438","messageId":"4D909DD1.2050904@viscovery.net","threadId":"26888","inReplyTo":"AANLkTin1QCda9BV+gND1kcXRTZBF7hj3Chce5OkLX2a9@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-03-28T14:40:17Z","receivedAt":"2011-03-28T14:40:17Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 3/28/2011 16:29, schrieb Andrew Garber:\n>> I'd expect this to work:\n>>\n>> $ git bisect start\n>> $ git bisect good\n>> $ git bisect bad HEAD~100\n> \n> So would I. I think the behavior of git bisect should be changed.\n> Right now, it's trying to find the first bad commit. Instead, it\n> should be trying to find the first commit where the code's good/bad\n> state *changed*. IOW, it should be able to handle both of the\n> following cases:\n> \n> good <--- oldest\n> good\n> good\n> bad <--- the commit we want bisect to find\n> bad\n> bad <--- newest\n> \n> bad <--- oldest\n> bad\n> bad\n> good <--- the commit we want bisect to find\n> good\n> good <--- newest\n> \n> It shouldn't matter which end we start on, so long as one end gets\n> marks good, and the other end gets marked bad.\n\nDefine \"end\" and \"other end\"! It's not that trivial.\n\n o--o--o--B\n /\n --o--o--o--o--G\n\nWhen I have this history and I mark B as bad and G as good, will I now\nfind the first bad or the first good commit?\n\n-- Hannes\n"},{"id":"164467","messageId":"AANLkTinC9Lr9uCTUZSVxVR56+FQm2NGRpPu90fm9OHF5@mail.gmail.com","threadId":"26888","inReplyTo":"4D909DD1.2050904@viscovery.net","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T17:18:18Z","receivedAt":"2011-03-28T17:18:18Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":"On Mon, Mar 28, 2011 at 10:40 AM, Johannes Sixt wrote:\n> Define \"end\" and \"other end\"! It's not that trivial.\n>\n>      o--o--o--B\n>     /\n>  --o--o--o--o--G\n>\n> When I have this history and I mark B as bad and G as good, will I now\n> find the first bad or the first good commit?\n>\n> -- Hannes\n>\n\nThat kind of situation shouldn't occur: IMO, bisect should only deal\nwith a single branch (the current branch).\n"},{"id":"164469","messageId":"vpq62r3i1z4.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"AANLkTinC9Lr9uCTUZSVxVR56+FQm2NGRpPu90fm9OHF5@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T17:33:51Z","receivedAt":"2011-03-28T17:33:51Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andrew Garber writes:\n\n> On Mon, Mar 28, 2011 at 10:40 AM, Johannes Sixt wrote:\n>\n>>      o--o--o--B\n>>     /\n>>  --o--o--o--o--G\n>>\n>> When I have this history and I mark B as bad and G as good, will I now\n>> find the first bad or the first good commit?\n>\n> That kind of situation shouldn't occur: IMO, bisect should only deal\n> with a single branch (the current branch).\n\nWhy?\n\nIt's not uncommon in real life to face the \"it works in branch foo but\nnot in branch bar, where did it break?\" problem. And one expects a great\ntool such as Git to be able to answer it.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164471","messageId":"AANLkTimT+WN2F-BmQzQrAs3uizHig9cCXDUdc7nQ-vC5@mail.gmail.com","threadId":"26888","inReplyTo":"vpq62r3i1z4.fsf@bauges.imag.fr","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T17:45:29Z","receivedAt":"2011-03-28T17:45:29Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":"If branch bar is broken, do a bisect on branch bar. The fact that\nbranch foo works in inconsequential.\n\nOn Mon, Mar 28, 2011 at 1:33 PM, Matthieu Moy\n wrote:\n> Andrew Garber writes:\n>\n>> On Mon, Mar 28, 2011 at 10:40 AM, Johannes Sixt wrote:\n>>\n>>>      o--o--o--B\n>>>     /\n>>>  --o--o--o--o--G\n>>>\n>>> When I have this history and I mark B as bad and G as good, will I now\n>>> find the first bad or the first good commit?\n>>\n>> That kind of situation shouldn't occur: IMO, bisect should only deal\n>> with a single branch (the current branch).\n>\n> Why?\n>\n> It's not uncommon in real life to face the \"it works in branch foo but\n> not in branch bar, where did it break?\" problem. And one expects a great\n> tool such as Git to be able to answer it.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n>\n"},{"id":"164472","messageId":"vpqr59r6sg5.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"AANLkTimT+WN2F-BmQzQrAs3uizHig9cCXDUdc7nQ-vC5@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T17:55:06Z","receivedAt":"2011-03-28T17:55:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"[ please do not top-post ]\n\nAndrew Garber writes:\n\n> If branch bar is broken, do a bisect on branch bar. The fact that\n> branch foo works in inconsequential.\n\nThen which commit do you specify as \"good\"?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164476","messageId":"AANLkTinuH4Ut+jtdqRfFrNeXA6JmBK2i0ddCcz4vV6JC@mail.gmail.com","threadId":"26888","inReplyTo":"vpqr59r6sg5.fsf@bauges.imag.fr","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T18:12:06Z","receivedAt":"2011-03-28T18:12:06Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":"On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy\n wrote:\n\n> Then which commit do you specify as \"good\"?\n\nAny ancestral commit *on the same branch* which is know to be working.\nIsn't the whole point of git bisect is to do binary search through\ntime? It only makes sense to me to use it on a single branch at a\ntime. Perhaps you could give a concrete example of where you could use\nit for multiple branches simultaneously?\n"},{"id":"164478","messageId":"vpqvcz35cjk.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"AANLkTinuH4Ut+jtdqRfFrNeXA6JmBK2i0ddCcz4vV6JC@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T18:23:59Z","receivedAt":"2011-03-28T18:23:59Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andrew Garber writes:\n\n> On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy\n> wrote:\n>\n>> Then which commit do you specify as \"good\"?\n>\n> Any ancestral commit *on the same branch* which is know to be working.\n\nWhat is the point is finding manually a commit *on the same branch* when\nthe tool can do that for you? You don't know how old the breakage is, so\nfinding the first good commit will take some time. Knowing that the\nother branch is good gives you a hint that the common ancestor between\nbranches should be good, so a good start would be to find the common\nancestor.\n\nBut again, why would you insist in doing that manually?\n\n> Isn't the whole point of git bisect is to do binary search through\n> time?\n\nNo. Bisect does a search through a DAG. And that is the whole point of\nbisect: doing a binary search through time is something you could do\nmanually. That would be less convenient, but still workable. git bisect\nis far more clever, and does something you could hardly do manually, or\nat least not without getting headaches.\n\n> Perhaps you could give a concrete example of where you could use it\n> for multiple branches simultaneously?\n\nWell, see my previous email.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164480","messageId":"AANLkTikADLZvN0N==_H47O1vcrap1_Mcf7vW69d5sh0d@mail.gmail.com","threadId":"26888","inReplyTo":"vpqvcz35cjk.fsf@bauges.imag.fr","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2011-03-28T18:57:38Z","receivedAt":"2011-03-28T18:57:38Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 28 March 2011 20:23, Matthieu Moy wrote:\n> Andrew Garber writes:\n>\n>> On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy\n>> wrote:\n>>\n>>> Then which commit do you specify as \"good\"?\n>>\n>> Any ancestral commit *on the same branch* which is know to be working.\n>\n> What is the point is finding manually a commit *on the same branch* when\n> the tool can do that for you? You don't know how old the breakage is, so\n> finding the first good commit will take some time. Knowing that the\n> other branch is good gives you a hint that the common ancestor between\n> branches should be good, so a good start would be to find the common\n> ancestor.\n\nThis doesn't make a lot of sense to me. It is just as likely NOT to be useful.\n\nIt could just as easily have been fixed in the other branch. So\nknowing its good wont tell you where it was broken.\n\nThis started off with:\n\n o--o--o--B\n /\n --o--o--o--o--G\n\nSo lets say that the reality of each node looks like this:\n\n B--B--B--B*\n /\n --B--B--B--G--G*\n\nHow does knowing that G* is good help us find what broke B* again?\n\nYour description matches the case of something like this:\n\n B--B--B--B*\n /\n --G--G--G--G--G*\n\nBut what about something like this:\n\n Bx--B--B--B*\n /\n --Gz--By--B--Gx--G*\n\nHow does knowing that G* is good help you to find that Bx broke the\ncode in the B* branch again?\n\nPresumably 'By' broke the G* branch which was then fixed by Gx and\nnone of this information helps you at all identify that Bx broke the\nB* branch.\n\nWhereas a plain binary search on the B* branch would eventually find\nthat Bx was responsible.\n\n>> Perhaps you could give a concrete example of where you could use it\n>> for multiple branches simultaneously?\n>\n> Well, see my previous email.\n\nWhere you said \"It's not uncommon in real life to face the \"it works\nin branch foo but\nnot in branch bar, where did it break?\" problem. And one expects a great\ntool such as Git to be able to answer it.\"\n\nSeems to me that this is trying to cram two questions into one:\n\nA) where did branch foo diverge from branch bar and\nB) which commit between that ancestor and bar did things break.\n\nOf course im probably missing something important here. Id like to\nknow what it is tho. :-)\n\ncheers,\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"164481","messageId":"AANLkTimR5XfOV-0RZjdyu72E9JdBfr1B+wc=q55V4qH5@mail.gmail.com","threadId":"26888","inReplyTo":"AANLkTikADLZvN0N==_H47O1vcrap1_Mcf7vW69d5sh0d@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T19:12:25Z","receivedAt":"2011-03-28T19:12:25Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":">> What is the point is finding manually a commit *on the same branch* when\n>> the tool can do that for you?\n\n> Seems to me that this is trying to cram two questions into one:\n>\n> A) where did branch foo diverge from branch bar and\n> B) which commit between that ancestor and bar did things break.\n\nTo find the answer to A, I generally just do this (using an alias):\n\ngit log --graph --oneline --all\n\nIt takes at most a couple of seconds... hardly what I'd call a manual process.\n"},{"id":"164485","messageId":"vpqbp0v2fve.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"AANLkTimR5XfOV-0RZjdyu72E9JdBfr1B+wc=q55V4qH5@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T19:40:21Z","receivedAt":"2011-03-28T19:40:21Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andrew Garber writes:\n\n>>> What is the point is finding manually a commit *on the same branch* when\n>>> the tool can do that for you?\n>\n>> Seems to me that this is trying to cram two questions into one:\n>>\n>> A) where did branch foo diverge from branch bar and\n>> B) which commit between that ancestor and bar did things break.\n\nNo. What I'm saying is that if you insist in not using bisect, you'll\nprobably have to answer these two questions separately.\n\n> To find the answer to A, I generally just do this (using an alias):\n>\n> git log --graph --oneline --all\n>\n> It takes at most a couple of seconds... hardly what I'd call a manual\n> process.\n\nSuppose you have a bug in git.git that you see in pu, but not in next.\nTry finding the common ancestor with your command, and see how long it\ntakes.\n\nYes, you'll be able to do it, but you still didn't tell us what was\nwrong with\n\ngit bisect start\ngit bisect good origin/next\ngit bisect bad origin/pu\n...\n\nwhich is _way_ faster. And my example took git.git which isn't a very\nlarge project, so real-life examples could be much worse.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164487","messageId":"AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com","threadId":"26888","inReplyTo":"vpqbp0v2fve.fsf@bauges.imag.fr","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andrew Garber","fromEmail":"andrew@andrewgarber.com","sentAt":"2011-03-28T20:12:49Z","receivedAt":"2011-03-28T20:12:49Z","isPatch":false,"sender":{"key":"andrew@andrewgarber.com","avatar":"https://avatars.githubusercontent.com/u/265048?v=4"},"body":"> Suppose you have a bug in git.git that you see in pu, but not in next.\n> Try finding the common ancestor with your command, and see how long it\n> takes.\n\nFair enough.\n\n> Yes, you'll be able to do it, but you still didn't tell us what was\n> wrong with\n>\n> git bisect start\n> git bisect good origin/next\n> git bisect bad origin/pu\n> ...\n>\n> which is _way_ faster. And my example took git.git which isn't a very\n> large project, so real-life examples could be much worse.\n\nBut what about demerphq's example? (see below)\n\n> Bx--B--B--B*\n> /\n> --Gz--By--B--Gx--G*\n>\n> How does knowing that G* is good help you to find that Bx broke the\n> code in the B* branch again?\n>\n> Presumably 'By' broke the G* branch which was then fixed by Gx and\n> none of this information helps you at all identify that Bx broke the\n> B* branch.\n>\n> Whereas a plain binary search on the B* branch would eventually find\n> that Bx was responsible.\n"},{"id":"164489","messageId":"20110328202521.GB27755@sigill.intra.peff.net","threadId":"26888","inReplyTo":"AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-28T20:25:21Z","receivedAt":"2011-03-28T20:25:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 28, 2011 at 04:12:49PM -0400, Andrew Garber wrote:\n\n> But what about demerphq's example? (see below)\n> \n> > Bx--B--B--B*\n> > /\n> > --Gz--By--B--Gx--G*\n> >\n> > How does knowing that G* is good help you to find that Bx broke the\n> > code in the B* branch again?\n> >\n> > Presumably 'By' broke the G* branch which was then fixed by Gx and\n> > none of this information helps you at all identify that Bx broke the\n> > B* branch.\n> >\n> > Whereas a plain binary search on the B* branch would eventually find\n> > that Bx was responsible.\n\nIf you feed bisect a history where the bug flips off and on between good\nand bad commits, you aren't necessarily going to get the answer you\nwant. But that has nothing to do with the history shape; it is a problem\nin a linear history like this, too:\n\n --G--Bx--B--G--G--By--B\n\nThat being said, it is more likely to happen with cherry-picking, which\nis more likely to happen with multiple branches. In git.git, we tend to\nfavor creating (or backporting) bugfix commits close to the bug itself,\nand then merging the same commit up.\n\n-Peff\n"},{"id":"164492","messageId":"vpqvcz3x9q0.fsf@bauges.imag.fr","threadId":"26888","inReplyTo":"AANLkTim+iQ89b49nC8NRtoUobV4tMVL+bCoW-vg3+rLD@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-03-28T20:37:27Z","receivedAt":"2011-03-28T20:37:27Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Andrew Garber writes:\n\n> But what about demerphq's example? (see below)\n>\n>> Bx--B--B--B*\n>> /\n>> --Gz--By--B--Gx--G*\n>>\n>> How does knowing that G* is good help you to find that Bx broke the\n>> code in the B* branch again?\n\nIf all you want is to know which commit introduced the bug, it doesn't.\nBut usually, what you're really looking for is an explanation and a fix\nfor the bug. Let's see what git bisect tells us then:\n\n$ git bisect start\n$ git bisect good \n$ git bisect bad \nBisecting: a merge base must be tested\n[f1fac16fb39dbe421b5cc4bcb945433495c794e1] ...\n$ git bisect bad\nThe merge base f1fac16fb39dbe421b5cc4bcb945433495c794e1 is bad.\nThis means the bug has been fixed between f1fac16fb39dbe421b5cc4bcb945433495c794e1\n and [089840ef9f8b97ddc9e28fa152c65115fb0b649a].\n\nThis doesn't tell you where the bug was introduced, but gives you\nsomething which is usually even more valuable: where to find the fix.\nThen, you have the choice between merging the good branch into the bad\none (like merging a maintainance branch into a dev branch), or to bisect\nagain to find the actual fix in good-branch.\n\nIf you really wanted to find the first bad commit, you've spent one\niteration sub-optimally and can start a new bisect with the merge base\nas the base commit.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"164498","messageId":"20110328212553.GA3334@sigill.intra.peff.net","threadId":"26888","inReplyTo":"20110328202521.GB27755@sigill.intra.peff.net","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-03-28T21:25:53Z","receivedAt":"2011-03-28T21:25:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 28, 2011 at 04:25:21PM -0400, Jeff King wrote:\n\n> On Mon, Mar 28, 2011 at 04:12:49PM -0400, Andrew Garber wrote:\n> \n> > But what about demerphq's example? (see below)\n> > \n> > > Bx--B--B--B*\n> > > /\n> > > --Gz--By--B--Gx--G*\n> > >\n> > > How does knowing that G* is good help you to find that Bx broke the\n> > > code in the B* branch again?\n> > >\n> > > Presumably 'By' broke the G* branch which was then fixed by Gx and\n> > > none of this information helps you at all identify that Bx broke the\n> > > B* branch.\n> > >\n> > > Whereas a plain binary search on the B* branch would eventually find\n> > > that Bx was responsible.\n> \n> If you feed bisect a history where the bug flips off and on between good\n> and bad commits, you aren't necessarily going to get the answer you\n> want. But that has nothing to do with the history shape; it is a problem\n> in a linear history like this, too:\n> \n> --G--Bx--B--G--G--By--B\n\nActually, scratch what I said. I misread his graph. The fix has not yet\nbeen cherry-picked, it just exists on the other branch. So there is no\nflipping. But as Matthieu explained in another response, there is still\nvalue in bisecting that graph.\n\n-Peff\n"},{"id":"164558","messageId":"4D91BA81.2020702@op5.se","threadId":"26888","inReplyTo":"AANLkTikADLZvN0N==_H47O1vcrap1_Mcf7vW69d5sh0d@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-03-29T10:54:57Z","receivedAt":"2011-03-29T10:54:57Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 03/28/2011 08:57 PM, demerphq wrote:\n> On 28 March 2011 20:23, Matthieu Moy wrote:\n>> Andrew Garber writes:\n>>\n>>> On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy\n>>> wrote:\n>>>\n>>>> Then which commit do you specify as \"good\"?\n>>>\n>>> Any ancestral commit *on the same branch* which is know to be working.\n>>\n>> What is the point is finding manually a commit *on the same branch* when\n>> the tool can do that for you? You don't know how old the breakage is, so\n>> finding the first good commit will take some time. Knowing that the\n>> other branch is good gives you a hint that the common ancestor between\n>> branches should be good, so a good start would be to find the common\n>> ancestor.\n> \n> This doesn't make a lot of sense to me. It is just as likely NOT to be useful.\n> \n> It could just as easily have been fixed in the other branch. So\n> knowing its good wont tell you where it was broken.\n> \n> This started off with:\n> \n> o--o--o--B\n> /\n> --o--o--o--o--G\n> \n> So lets say that the reality of each node looks like this:\n> \n> B--B--B--B*\n> /\n> --B--B--B--G--G*\n> \n> How does knowing that G* is good help us find what broke B* again?\n> \n\nBecause if G* is good and B* is bad, git-bisect knows to look for\nthe merge-base (the leftmost lower B in your graph) to know that\nit's not looking at uninteresting commits.\n\n> Your description matches the case of something like this:\n> \n> B--B--B--B*\n> /\n> --G--G--G--G--G*\n> \n> But what about something like this:\n> \n> Bx--B--B--B*\n> /\n> --Gz--By--B--Gx--G*\n> \n> How does knowing that G* is good help you to find that Bx broke the\n> code in the B* branch again?\n> \n\nBecause it helps locate Gz as the common ancestor between G* and B*.\n\nTo bisect a problem with B*, you'd mark B* as bad and, assuming Gz is\na stable release from which the feature-branch B has arisen, you'd\nmark Gz as good. Then bisect will quite quickly find that Bx is the\nculprit.\n\nOr, if G* works well but B* does not and you can't be arsed to locate\nthe common ancestor yourself, you mark G* as good and B* as bad and then\ngit-bisect will automatically reset the \"good\" mark from G* to Gz. This\nofcourse doesn't work when the two points in doesn't share a common\nancestor, although that should be a rare occasion indeed and won't\nmake much sense.\n\n> Presumably 'By' broke the G* branch which was then fixed by Gx and\n> none of this information helps you at all identify that Bx broke the\n> B* branch.\n> \n\nYou're right. For that, you'd need two different bisects. If the two\nbreakages are identical (an unlikely situation, but still), you'd end\nup with git-bisect finding a single commit when marking GB* (the merge\nof G* and B*) as bad and Gz as good. Which one is hard to tell though.\nBut then again, git-bisect has never claimed to be able to locate all\nbugs at once. It can just help you locate where a particular bug was\nintroduced.\n\nThere are some cases where it will fail quite gruesomely though. When\none bug is covered by another and fixing the first bug uncovers the\none you're bisecting for. Even then it will still cut down considerably\non time spent doing implemetation analysis (aka \"staring at code\").\n\n> Whereas a plain binary search on the B* branch would eventually find\n> that Bx was responsible.\n> \n\nTrue, but a binary search would mean about a bazillion git-bisect runs\non large and complex history (such as the kernel, or git itself) when\nthe bug is located in an already merged feature-branch, but noone knows\nwhich one.\n\n>>> Perhaps you could give a concrete example of where you could use it\n>>> for multiple branches simultaneously?\n>>\n>> Well, see my previous email.\n> \n> Where you said \"It's not uncommon in real life to face the \"it works\n> in branch foo but\n> not in branch bar, where did it break?\" problem. And one expects a great\n> tool such as Git to be able to answer it.\"\n> \n> Seems to me that this is trying to cram two questions into one:\n> \n> A) where did branch foo diverge from branch bar and\n> B) which commit between that ancestor and bar did things break.\n> \n\nThe only question git-bisect tries to answer is \"which is the first\nbad commit\". If you want the implementation details, I suggest you\nread the code, but naturally it knows how to walk the DAG it's\ninspecting and naturally it tries to make life easier for the human\nit inevitable serves.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"168453","messageId":"BANLkTinx1oaqcUSZo-fRAZeHfuoFifVNGQ@mail.gmail.com","threadId":"26888","inReplyTo":"AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com","subject":"Re: Why can't I use git-bisect to find the first *good* commit?","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-05-22T19:41:07Z","receivedAt":"2011-05-22T19:41:07Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Mon, Mar 28, 2011 at 09:32, Ævar Arnfjörð Bjarmason wrote:\n> But instead I have to do:\n>\n>    $ git bisect start\n>    $ git bisect bad\n>    $ git bisect good HEAD~100\n>\n> And then proceed to mark good revisions as bad, and bad revisions as\n> good.\n>\n> That works, but it's very confusing.\n>\n\nTo me, at least, that seems perfectly reasonable.\n\nIn particular, the problem seems to be your own thinking:\n\n> And then proceed to mark good revisions as bad, and bad revisions as\n> good.\n\nDon't think of it like that.\n"}]}