{"thread":{"id":"47166","subject":"\"git bisect\" takes exactly one bad commit and one or more good?","startedAt":"2017-11-11T11:22:47Z","lastAt":"2017-11-12T21:14:16Z","messageCount":7,"participants":["Robert P. J. Day","Christian Couder","Junio C Hamano","Kaartic Sivaraam","Stephan Beyer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"332278","messageId":"alpine.LFD.2.21.1711110612290.5087@localhost.localdomain","threadId":"47166","inReplyTo":null,"subject":"\"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T11:22:17Z","receivedAt":"2017-11-11T11:22:47Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n more on \"git bisect\" ... the man page seems to make it clear that\nbisection takes *precisely* one \"bad\" commit, and one *or more* good\ncommits, is that correct? seems that way, given the ellipses in the\ncommands below:\n\n git bisect start [--term-{old,good}= --term-{new,bad}=]\n [--no-checkout] [ [...]] [--] [...]\n git bisect (bad|new|) []\n git bisect (good|old|) [...]\n\nhowever, other parts of the man page seem less clear. just below\nthat, a description that bisection takes \"a\" good commit:\n\n\"You use it by first telling it a \"bad\" commit that is known to\ncontain the bug, and a \"good\" commit that is known to be before the\nbug was introduced.\"\n\nand a bit lower, we read \"at least one bad ...\", which some people\nmight interpret as one or more *bad* commits:\n\n\"Once you have specified at least one bad and one good commit, git\nbisect selects a commit in the middle of that range of history, checks\nit out, and outputs something similar to the following:\"\n\n if the rules are exactly one bad commit and one or more good, i'll\nsubmit a patch to reword at least the above, and possibly more if\nnecessary.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"332280","messageId":"CAP8UFD1=idL51XDzE_RKc_7z9NghTd7GHoZ-T61y0rQ8ZYXomw@mail.gmail.com","threadId":"47166","inReplyTo":"alpine.LFD.2.21.1711110612290.5087@localhost.localdomain","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-11-11T12:01:43Z","receivedAt":"2017-11-11T12:01:49Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Nov 11, 2017 at 12:22 PM, Robert P. J. Day\n wrote:\n>\n> more on \"git bisect\" ... the man page seems to make it clear that\n> bisection takes *precisely* one \"bad\" commit, and one *or more* good\n> commits, is that correct?\n\nYeah, that's true.\n\n> seems that way, given the ellipses in the\n> commands below:\n>\n> git bisect start [--term-{old,good}= --term-{new,bad}=]\n> [--no-checkout] [ [...]] [--] [...]\n> git bisect (bad|new|) []\n> git bisect (good|old|) [...]\n\nYeah indeed.\n\n> however, other parts of the man page seem less clear. just below\n> that, a description that bisection takes \"a\" good commit:\n>\n> \"You use it by first telling it a \"bad\" commit that is known to\n> contain the bug, and a \"good\" commit that is known to be before the\n> bug was introduced.\"\n\nYeah, 'and at least a \"good\" commit' would be better.\n\n> and a bit lower, we read \"at least one bad ...\", which some people\n> might interpret as one or more *bad* commits:\n>\n> \"Once you have specified at least one bad and one good commit, git\n> bisect selects a commit in the middle of that range of history, checks\n> it out, and outputs something similar to the following:\"\n\nYeah, 'Once you have specified one bad and at least one good commit'\nwould be better.\n\n> if the rules are exactly one bad commit and one or more good, i'll\n> submit a patch to reword at least the above, and possibly more if\n> necessary.\n\nSure, thanks,\nChristian.\n"},{"id":"332290","messageId":"xmqq8tfcevev.fsf@gitster.mtv.corp.google.com","threadId":"47166","inReplyTo":"CAP8UFD1=idL51XDzE_RKc_7z9NghTd7GHoZ-T61y0rQ8ZYXomw@mail.gmail.com","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-11T14:34:32Z","receivedAt":"2017-11-11T14:34:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n>> \"You use it by first telling it a \"bad\" commit that is known to\n>> contain the bug, and a \"good\" commit that is known to be before the\n>> bug was introduced.\"\n>\n> Yeah, 'and at least a \"good\" commit' would be better.\n\nMake it \"at least one\" instead, perhaps?\n\nI somehow thought that you technically could force bisection with 0\ngood commit, even though no sane person would do so. For the\nmatter, in practice nobody starts with more than one good commit,\nand for that reason, I doubt that the proposed change to overstress\nthe fact that you could give two or more \"good\" ones when starting\nhas that much practical value. The tradeoff of losing the clarity\ncoming from giving only the simplest usage pattern for trying to be\ntechnically more correct that is proposed by this change does not\nsound too good, but it may be just me (who prefers white lies in the\nend-user docs when it buys us more simplicity and clarity).\n.\n\n"},{"id":"332292","messageId":"alpine.LFD.2.21.1711111024470.10756@localhost.localdomain","threadId":"47166","inReplyTo":"xmqq8tfcevev.fsf@gitster.mtv.corp.google.com","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T15:27:45Z","receivedAt":"2017-11-11T15:28:16Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sat, 11 Nov 2017, Junio C Hamano wrote:\n\n> Christian Couder writes:\n>\n> >> \"You use it by first telling it a \"bad\" commit that is known to\n> >> contain the bug, and a \"good\" commit that is known to be before\n> >> the bug was introduced.\"\n> >\n> > Yeah, 'and at least a \"good\" commit' would be better.\n>\n> Make it \"at least one\" instead, perhaps?\n>\n> I somehow thought that you technically could force bisection with 0\n> good commit, even though no sane person would do so. For the\n> matter, in practice nobody starts with more than one good commit,\n> and for that reason, I doubt that the proposed change to overstress\n> the fact that you could give two or more \"good\" ones when starting\n> has that much practical value. The tradeoff of losing the clarity\n> coming from giving only the simplest usage pattern for trying to be\n> technically more correct that is proposed by this change does not\n> sound too good, but it may be just me (who prefers white lies in the\n> end-user docs when it buys us more simplicity and clarity). .\n\n i realize that one of each commit is the simplest use case, but the\nscenario that occurred to me is a bunch of branches being merged and,\nsuddenly, you have a bug, and you're not sure where it came from so\nyou identify a number of good commits, one per merged branch, and go\nfrom there.\n\n also, making it clear you can have more than one good commit is\nconsistent with the synopses, which use ellipses to represent that\nvery thing.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"332294","messageId":"alpine.LFD.2.21.1711111101370.11260@localhost.localdomain","threadId":"47166","inReplyTo":"xmqq8tfcevev.fsf@gitster.mtv.corp.google.com","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T16:03:52Z","receivedAt":"2017-11-11T16:04:21Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sat, 11 Nov 2017, Junio C Hamano wrote:\n\n> Christian Couder writes:\n>\n> >> \"You use it by first telling it a \"bad\" commit that is known to\n> >> contain the bug, and a \"good\" commit that is known to be before the\n> >> bug was introduced.\"\n> >\n> > Yeah, 'and at least a \"good\" commit' would be better.\n>\n> Make it \"at least one\" instead, perhaps?\n>\n> I somehow thought that you technically could force bisection with 0\n> good commit, even though no sane person would do so...\n\n i do see the following snippet in bisect_next_check():\n\n bisect_next_check() {\n\n ... snip ...\n\n case \"$missing_good,$missing_bad,$1\" in\n ,,*)\n : have both $TERM_GOOD and $TERM_BAD - ok\n ;;\n *,)\n # do not have both but not asked to fail - just report.\n false\n ;;\n t,,\"$TERM_GOOD\")\n # have bad (or new) but not good (or old). we could bisect although\n # this is less optimum.\n eval_gettextln \"Warning: bisecting only with a \\$TERM_BAD commit.\" >&2\n\n ... snip ...\n\nso i guess it's possible.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"332321","messageId":"1510488875.2683.3.camel@gmail.com","threadId":"47166","inReplyTo":"alpine.LFD.2.21.1711111024470.10756@localhost.localdomain","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-11-12T12:14:35Z","receivedAt":"2017-11-12T12:14:47Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sat, 2017-11-11 at 10:27 -0500, Robert P. J. Day wrote:\n> \n> i realize that one of each commit is the simplest use case, but the\n> scenario that occurred to me is a bunch of branches being merged and,\n> suddenly, you have a bug, and you're not sure where it came from so\n> you identify a number of good commits, one per merged branch, and go\n> from there.\n> \n> \n\nJust thinking out loud, couldn't you give the one commit that was the\ntip of the branch, to which you merged the branches, before you merged\nin the branches as the good commit ?\n\n\n-- \nKaartic\n"},{"id":"332366","messageId":"4cc5519b-f384-f9e7-3261-f36e1943a776@gmx.net","threadId":"47166","inReplyTo":"xmqq8tfcevev.fsf@gitster.mtv.corp.google.com","subject":"Re: \"git bisect\" takes exactly one bad commit and one or more good?","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2017-11-12T21:13:15Z","receivedAt":"2017-11-12T21:14:16Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"On 11/11/2017 03:34 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n> \n>>> \"You use it by first telling it a \"bad\" commit that is known to\n>>> contain the bug, and a \"good\" commit that is known to be before the\n>>> bug was introduced.\"\n>>\n>> Yeah, 'and at least a \"good\" commit' would be better.\n> \n> Make it \"at least one\" instead, perhaps?\n> \n> I somehow thought that you technically could force bisection with 0\n> good commit, even though no sane person would do so.\n\nThanks for pointing that out but I disagree with the part after \"even\nthough\" :)\n\nImagine you add a test case that was totally uncovered before and now\nreveals a bug. You want to find the introduction of the bug, so you can\neither check out the first commit you think where that bug did not\nexist, then you find out that its also a bad commit, so you check out\nanother commit... essentially you are manually doing a \"bisect\" but less\nefficient. So it would be better to let \"git bisect\" do its job without\nknowing a good commit in advance. Sounds perfectly sane to me.\n\nThe probably insane thing is that there are currently performance issues\nwith git bisect. So you *are* probably faster by guessing. But that is\nwhat my patch series [1] was about (and that I postponed in favor of\nother conflicting work on bisect).\n\n1.\nhttps://public-inbox.org/git/1460294354-7031-1-git-send-email-s-beyer@gmx.net/\n\nCheers\nStephan\n"}]}