{"thread":{"id":"47167","subject":"should \"git bisect\" support \"git bisect next?\"","startedAt":"2017-11-11T11:43:22Z","lastAt":"2017-11-13T01:40:53Z","messageCount":11,"participants":["Robert P. J. Day","Christian Couder","Junio C Hamano","Theodore Ts'o","Stephan Beyer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"332279","messageId":"alpine.LFD.2.21.1711110639120.5632@localhost.localdomain","threadId":"47167","inReplyTo":null,"subject":"should \"git bisect\" support \"git bisect next?\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-11T11:42:53Z","receivedAt":"2017-11-11T11:43:22Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  the man page for \"git bisect\" makes no mention of \"git bisect next\",\nbut the script git-bisect.sh does:\n\n#!/bin/sh\n\nUSAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'\n                                               ^^^^\nLONG_USAGE='git bisect help\n        print this long help message.\ngit bisect start [--term-{old,good}=<term> --term-{new,bad}=<term>]\n                 [--no-checkout] [<bad> [<good>...]] [--] [<pathspec>...]\n        reset bisect state and start bisection.\ngit bisect (bad|new) [<rev>]\n        mark <rev> a known-bad revision/\n                a revision after change in a given property.\ngit bisect (good|old) [<rev>...]\n        mark <rev>... known-good revisions/\n                revisions before change in a given property.\ngit bisect terms [--term-good | --term-bad]\n        show the terms used for old and new commits (default: bad, good)\ngit bisect skip [(<rev>|<range>)...]\n        mark <rev>... untestable revisions.\ngit bisect next\n        find next bisection to test and check it out.\n\n  ... snip ...\n\ncase \"$#\" in\n0)\n        usage ;;\n*)\n        cmd=\"$1\"\n        get_terms\n        shift\n        case \"$cmd\" in\n        help)\n                git bisect -h ;;\n        start)\n                bisect_start \"$@\" ;;\n        bad|good|new|old|\"$TERM_BAD\"|\"$TERM_GOOD\")\n                bisect_state \"$cmd\" \"$@\" ;;\n        skip)\n                bisect_skip \"$@\" ;;\n        next)\n                # Not sure we want \"next\" at the UI level anymore.\n                bisect_next \"$@\" ;;\n\n  ... snip ...\n\nso, is it supported or not? should be consistent.\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":"332287","messageId":"CAP8UFD3az17BpB0nA+35p3BP95sBuOY0Yvce3cgbh0L3YH7+rQ@mail.gmail.com","threadId":"47167","inReplyTo":"alpine.LFD.2.21.1711110639120.5632@localhost.localdomain","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-11-11T14:07:55Z","receivedAt":"2017-11-11T14:08:01Z","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:42 PM, Robert P. J. Day\n<rpjday@crashcourse.ca> wrote:\n>\n>   the man page for \"git bisect\" makes no mention of \"git bisect next\",\n> but the script git-bisect.sh does:\n\nYeah the following patch was related:\n\nhttps://public-inbox.org/git/1460294354-7031-2-git-send-email-s-beyer@gmx.net/\n\nYou might want to discuss with Stephan (cc'ed).\n\nThanks,\nChristian.\n"},{"id":"332291","messageId":"xmqq4lq0ev8g.fsf@gitster.mtv.corp.google.com","threadId":"47167","inReplyTo":"CAP8UFD3az17BpB0nA+35p3BP95sBuOY0Yvce3cgbh0L3YH7+rQ@mail.gmail.com","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-11T14:38:23Z","receivedAt":"2017-11-11T14:38:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> On Sat, Nov 11, 2017 at 12:42 PM, Robert P. J. Day\n> <rpjday@crashcourse.ca> wrote:\n>>\n>>   the man page for \"git bisect\" makes no mention of \"git bisect next\",\n>> but the script git-bisect.sh does:\n>\n> Yeah the following patch was related:\n>\n> https://public-inbox.org/git/1460294354-7031-2-git-send-email-s-beyer@gmx.net/\n>\n> You might want to discuss with Stephan (cc'ed).\n\nThanks for saving me time to explain why 'next' is still a very\nimportant command but the end users do not actually need to be\nstrongly aware of it, because most commands automatically invokes it\nas their final step due to the importance of what it does ;-)\n\n"},{"id":"332302","messageId":"20171111194616.a2hl4dwz5cycuzdh@thunk.org","threadId":"47167","inReplyTo":"xmqq4lq0ev8g.fsf@gitster.mtv.corp.google.com","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2017-11-11T19:46:16Z","receivedAt":"2017-11-11T19:46:28Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote:\n> \n> Thanks for saving me time to explain why 'next' is still a very\n> important command but the end users do not actually need to be\n> strongly aware of it, because most commands automatically invokes it\n> as their final step due to the importance of what it does ;-)\n\nThis reminds me; is there a way to suppress it because I'm about to\ngive a large set of good and bit commits (perhaps because I'm\nreplaying part of a git biset log, minus one or two lines that are\nsuspected of being bogus thanks to flaky reproduction), and so there's\nno point having git bisect figure the \"next\" commit to try until I'm\ndone giving it a list of good/bad commits?\n\n\t     \t       \t      \t \t  - Ted\n"},{"id":"332304","messageId":"xmqqvaigclv0.fsf@gitster.mtv.corp.google.com","threadId":"47167","inReplyTo":"20171111194616.a2hl4dwz5cycuzdh@thunk.org","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-12T01:43:47Z","receivedAt":"2017-11-12T01:43:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o <tytso@mit.edu> writes:\n\n> On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote:\n>> \n>> Thanks for saving me time to explain why 'next' is still a very\n>> important command but the end users do not actually need to be\n>> strongly aware of it, because most commands automatically invokes it\n>> as their final step due to the importance of what it does ;-)\n>\n> This reminds me; is there a way to suppress it because I'm about to\n> give a large set of good and bit commits (perhaps because I'm\n> replaying part of a git biset log, minus one or two lines that are\n> suspected of being bogus thanks to flaky reproduction), and so there's\n> no point having git bisect figure the \"next\" commit to try until I'm\n> done giving it a list of good/bad commits?\n\nIt is surprising that I've never heard of this idea, but I think\nthat it is an excellent one.\n\nWhen the user knows what bad and good commits in what sequence will\nbe fed to the command (i.e. replaying a saved output of \"git bisect\nlog\"), ideally we would want to \"plug\" the auto-next processing, and\njust mark good and bad in refs/bisect/* without doing anything other\nthan creating these refs, and then run a \"next\" before giving the\ncontrol back to present the final working tree to be tested by the\nuser.  That would save the cost of intermediate checkouts but also\nthe cost of extra merge-base computation that is done to catch the\ncase where the user gave a good commit that is an ancestor of a bad\ncommit by mistake.\n\nI think that the output of \"git bisect log\" was designed to be just\nan executable shell script that the user can edit (the edit is\nmostly designed to make it possible: \"I know I screwed up in this\nstep, so I change its 'bad' to 'good' and remove the remaining\nlines\") and just execute it.  Which makes the simplest approach that\nwould first come to my mind not work very well, unfortunately.\n\n\tThe \"simplest approach\" would teach the \"--no-autonext\"\n\toption to \"git bisect good\" and \"git bisect bad\" and skip\n\tthe call to bisect_auto_next in bisect_state when it is\n\tgiven.  Then update the output from \"git bisect log\" to add\n\tthat option to all good/bad commands, and then add an\n\texplicit \"git bisect next\" at the end.  This won't work well\n\tbecause it is likely that with the \"remove the remaining\n\tlines\" step, it is likely that the user would remove the\n\tfinal \"bisect next\".\n\nA workable alternative approach is to teach \"git bisect replay\" to\nbe more intelligent.  Right now, I do not think it does anything\nmore than what happens by an execution of the input file with a\nshell, but \"replay\" should be able to read a single step ahead in\nthe command sequence while doing its step-by-step execution, and\nwhen it notices that it is about to run \"bisect good\" or \"bisect\nbad\", and if the command to be run after that is also one of these\ntwo, it can decide to skip the auto-next processing in the current\nstep.  It shouldn't need any new \"--no-auto-next\" option (I am not\nsaying that adding the option is bad--in fact, I think it is a good\naddition for expert users; I am just saying that the approach to\nmake \"replay\" smarter does not require it).\n\nChristian, what do you think?  Am I missing something?\n"},{"id":"332311","messageId":"alpine.LFD.2.21.1711120415190.28956@localhost.localdomain","threadId":"47167","inReplyTo":"20171111194616.a2hl4dwz5cycuzdh@thunk.org","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2017-11-12T09:17:20Z","receivedAt":"2017-11-12T09:18:01Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sat, 11 Nov 2017, Theodore Ts'o wrote:\n\n> On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote:\n> >\n> > Thanks for saving me time to explain why 'next' is still a very\n> > important command but the end users do not actually need to be\n> > strongly aware of it, because most commands automatically invokes\n> > it as their final step due to the importance of what it does ;-)\n>\n> This reminds me; is there a way to suppress it because I'm about to\n> give a large set of good and bit commits (perhaps because I'm\n                      ^^^^^^^^^^^^^^^^^^^^\n> replaying part of a git biset log, minus one or two lines that are\n> suspected of being bogus thanks to flaky reproduction), and so\n> there's no point having git bisect figure the \"next\" commit to try\n> until I'm done giving it a list of good/bad commits?\n\n  i'm sure i'll regret asking this, but (assuming \"bit\" should read\n\"bad\") is this suggesting one can hand bisect more than one bad\ncommit? i thought we just went through that discussion where there\ncould be only one bad commit but multiple good commits. clarification?\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":"332316","messageId":"xmqq4lpzddmv.fsf@gitster.mtv.corp.google.com","threadId":"47167","inReplyTo":"alpine.LFD.2.21.1711120415190.28956@localhost.localdomain","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-12T09:56:08Z","receivedAt":"2017-11-12T09:56:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n\n>> This reminds me; is there a way to suppress it because I'm about to\n>> give a large set of good and bit commits (perhaps because I'm\n>                       ^^^^^^^^^^^^^^^^^^^^\n>> replaying part of a git biset log, minus one or two lines that are\n>> suspected of being bogus thanks to flaky reproduction), and so\n>> there's no point having git bisect figure the \"next\" commit to try\n>> until I'm done giving it a list of good/bad commits?\n>\n>   i'm sure i'll regret asking this, but (assuming \"bit\" should read\n> \"bad\") is this suggesting one can hand bisect more than one bad\n> commit? i thought we just went through that discussion where there\n> could be only one bad commit but multiple good commits. clarification?\n\nThe documentation you have been futzing with is about the fact that\nthe initial set of known to be good/bad commits that \"git bisect\nstart <bad> <good>...\" take can have one bad and zero or more good.\n\nWhat is being discussed in this thread is different (and I tried to\nclarify the fact by saying \"what bad and good commits in what\nsequence\").  \n\nTed is talking about replaying the series of \"git bisect (good|bad)\n$a_single_commit\" that are recorded during a bisection session and\ncan be read via \"git bisect log\".  When Ted says \"good commits\"\nand/or \"bad commits\", he is not talking about giving all of them to\na single invocation of \"git bisect\" command.  The replay session\nwill take one commit at a time (which is what \"git bisect replay\"\ndoes) and feed it to either \"git bisect good\" or \"git bisect bad\".\n\nDoes it make sense?\n\nBy the way, I do not think there is anything to regret in asking\nwhat you do not understand.  Showing how much you know (and you\ndon't) will allow others who communicate with you to calibrate their\nexpectations, which eases later discussions; it is a good thing.\n"},{"id":"332332","messageId":"CAP8UFD3DzdTf6-yZVwMvc1=nP+ejrinjvE8wAPhdaHoOQOmpGw@mail.gmail.com","threadId":"47167","inReplyTo":"xmqqvaigclv0.fsf@gitster.mtv.corp.google.com","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-11-12T14:21:57Z","receivedAt":"2017-11-12T14:22:04Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Nov 12, 2017 at 2:43 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Theodore Ts'o <tytso@mit.edu> writes:\n>\n>> On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote:\n>>>\n>>> Thanks for saving me time to explain why 'next' is still a very\n>>> important command but the end users do not actually need to be\n>>> strongly aware of it, because most commands automatically invokes it\n>>> as their final step due to the importance of what it does ;-)\n>>\n>> This reminds me; is there a way to suppress it because I'm about to\n>> give a large set of good and bit commits (perhaps because I'm\n>> replaying part of a git biset log, minus one or two lines that are\n>> suspected of being bogus thanks to flaky reproduction), and so there's\n>> no point having git bisect figure the \"next\" commit to try until I'm\n>> done giving it a list of good/bad commits?\n>\n> It is surprising that I've never heard of this idea, but I think\n> that it is an excellent one.\n>\n> When the user knows what bad and good commits in what sequence will\n> be fed to the command (i.e. replaying a saved output of \"git bisect\n> log\"), ideally we would want to \"plug\" the auto-next processing, and\n> just mark good and bad in refs/bisect/* without doing anything other\n> than creating these refs, and then run a \"next\" before giving the\n> control back to present the final working tree to be tested by the\n> user.  That would save the cost of intermediate checkouts but also\n> the cost of extra merge-base computation that is done to catch the\n> case where the user gave a good commit that is an ancestor of a bad\n> commit by mistake.\n\nYeah I agree that it might be something interesting for the user to do.\nBut in this case the sequence in which you give the good and the bad\ncommits is not important.\nOnly the last bad commit and the set of good commits that were given\nare important.\n\nIf you can get that and pass it to 'git bisect start' then you will\navoid all the intermediate computation and actually start from the\nstate you want.\n\n> I think that the output of \"git bisect log\" was designed to be just\n> an executable shell script that the user can edit (the edit is\n> mostly designed to make it possible: \"I know I screwed up in this\n> step, so I change its 'bad' to 'good' and remove the remaining\n> lines\") and just execute it.  Which makes the simplest approach that\n> would first come to my mind not work very well, unfortunately.\n>\n>         The \"simplest approach\" would teach the \"--no-autonext\"\n>         option to \"git bisect good\" and \"git bisect bad\" and skip\n>         the call to bisect_auto_next in bisect_state when it is\n>         given.  Then update the output from \"git bisect log\" to add\n>         that option to all good/bad commands, and then add an\n>         explicit \"git bisect next\" at the end.  This won't work well\n>         because it is likely that with the \"remove the remaining\n>         lines\" step, it is likely that the user would remove the\n>         final \"bisect next\".\n>\n> A workable alternative approach is to teach \"git bisect replay\" to\n> be more intelligent.  Right now, I do not think it does anything\n> more than what happens by an execution of the input file with a\n> shell, but \"replay\" should be able to read a single step ahead in\n> the command sequence while doing its step-by-step execution, and\n> when it notices that it is about to run \"bisect good\" or \"bisect\n> bad\", and if the command to be run after that is also one of these\n> two, it can decide to skip the auto-next processing in the current\n> step.  It shouldn't need any new \"--no-auto-next\" option (I am not\n> saying that adding the option is bad--in fact, I think it is a good\n> addition for expert users; I am just saying that the approach to\n> make \"replay\" smarter does not require it).\n\nTo automate that one could start with a dirty oneliner like this:\n\ngit bisect start $(git bisect log | perl -ne '$b = $1 if m/# bad:\n\\[(.*)\\]/; push @g, $1 if m/# good: \\[(.*)\\]/; END { print $b . \" \".\njoin(\" \", @g) . \"\\n\"; }')\n\nSo yeah we could add an option to \"git replay\" that would do that.\n"},{"id":"332354","messageId":"20171112184252.vpasjhfkt63izrun@thunk.org","threadId":"47167","inReplyTo":"CAP8UFD3DzdTf6-yZVwMvc1=nP+ejrinjvE8wAPhdaHoOQOmpGw@mail.gmail.com","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2017-11-12T18:42:52Z","receivedAt":"2017-11-12T18:43:04Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote:\n> \n> Yeah I agree that it might be something interesting for the user to do.\n> But in this case the sequence in which you give the good and the bad\n> commits is not important.\n> Only the last bad commit and the set of good commits that were given\n> are important.\n\nIs it really true that of the bad commits, only the last one is significant?\n\nSuppose we have a git tree that looks like this:\n\n          *---*---*---*---*---*---M2---*---B1\n          |                        |\n  G1--*--D1---*---*---*---B2-\\     |\n          |                   \\    /\n          *---*---*---B3--*---M1--/\n\nIf we know that commits B2 and B3 are bad, if we assume that all\ncommits before the \"bad\" commit are good, all commits after the \"bad\"\ncommit are bad, can we not deduce that commit D1 should also be \"bad\"?\n\n       \t   \t       \t   \t       \t      - Ted\n"},{"id":"332360","messageId":"cc11ab35-a219-8cab-313e-f716723409e4@gmx.net","threadId":"47167","inReplyTo":"xmqq4lq0ev8g.fsf@gitster.mtv.corp.google.com","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2017-11-12T20:08:35Z","receivedAt":"2017-11-12T20:09:40Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn 11/11/2017 03:38 PM, Junio C Hamano wrote:\n> Christian Couder <christian.couder@gmail.com> writes:\n> \n>> On Sat, Nov 11, 2017 at 12:42 PM, Robert P. J. Day\n>> <rpjday@crashcourse.ca> wrote:\n>>>\n>>>   the man page for \"git bisect\" makes no mention of \"git bisect next\",\n>>> but the script git-bisect.sh does:\n>>\n>> Yeah the following patch was related:\n>>\n>> https://public-inbox.org/git/1460294354-7031-2-git-send-email-s-beyer@gmx.net/\n>>\n>> You might want to discuss with Stephan (cc'ed).\n> \n> Thanks for saving me time to explain why 'next' is still a very\n> important command but the end users do not actually need to be\n> strongly aware of it, because most commands automatically invokes it\n> as their final step due to the importance of what it does ;-)\n\nI will nonetheless re-roll the patch (that Christian linked to)\nafter Pranit's bisect part II series is in good shape. I think the\ndocumentation change in the patch shows why the user should be aware of\nit (although not strongly).\n\nBest\nStephan\n\n"},{"id":"332378","messageId":"xmqqpo8narc3.fsf@gitster.mtv.corp.google.com","threadId":"47167","inReplyTo":"20171112184252.vpasjhfkt63izrun@thunk.org","subject":"Re: should \"git bisect\" support \"git bisect next?\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-11-13T01:40:44Z","receivedAt":"2017-11-13T01:40:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Ts'o <tytso@mit.edu> writes:\n\n> On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote:\n>> \n>> Yeah I agree that it might be something interesting for the user to do.\n>> But in this case the sequence in which you give the good and the bad\n>> commits is not important.\n>> Only the last bad commit and the set of good commits that were given\n>> are important.\n>\n> Is it really true that of the bad commits, only the last one is significant?\n>\n> Suppose we have a git tree that looks like this:\n>\n>           *---*---*---*---*---*---M2---*---B1\n>           |                        |\n>   G1--*--D1---*---*---*---B2-\\     |\n>           |                   \\    /\n>           *---*---*---B3--*---M1--/\n>\n> If we know that commits B2 and B3 are bad, if we assume that all\n> commits before the \"bad\" commit are good, all commits after the \"bad\"\n> commit are bad, can we not deduce that commit D1 should also be \"bad\"?\n\nYou are correct.  Christian fell into an understandable and common\nconfusion.  It is true that we only maintain one significant bad\n(i.e. the breakage that is known-ealiest so far), but that oldest\nbad is the result of the bisection taking into account all the 'bad'\nwe have got in sequence so far, not necessarily the same as, and\nhopefully way better than, the last bad the user gave from the\ncommand line.  In your topology, \"git bisect log\" would contain \"bad\nB1\", \"bad B2\", and \"bad B3\", and when the earlier session that\nproduced that log saw these three bad commits, it would have marked\nD1 as the known-earliest bad one.\n\nTaking the last-given bad B3 is suboptimal than that.\n"}]}