{"thread":{"id":"42958","subject":"git bisect for reachable commits only","startedAt":"2016-07-29T08:54:02Z","lastAt":"2016-08-04T23:29:48Z","messageCount":14,"participants":["Oleg Taranenko","Junio C Hamano","Jakub Narębski","Christian Couder","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"292503","messageId":"CABEd3j8VLbpeWbA6BfHYp5aLPEy0PesqYoHM9u4OM=b7Qm=LDg@mail.gmail.com","threadId":"42958","inReplyTo":null,"subject":"git bisect for reachable commits only","fromName":"Oleg Taranenko","fromEmail":"olegtaranenko@gmail.com","sentAt":"2016-07-29T08:53:56Z","receivedAt":"2016-07-29T08:54:02Z","isPatch":false,"sender":{"key":"olegtaranenko@gmail.com","avatar":"https://gravatar.com/avatar/016106c4926412cef4141b2d7cea4378aef44db0ca56c9462a5f4a71c7a80955?d=mp&s=160"},"body":"Hi all,\n\n\nI just found an interesting post how git bisect can trouble humans.\nFull story is here\nhttps://groups.google.com/forum/#!topic/git-users/v3__t42qbKE\n\n\nMy suggestion to fix it (ditto)\n\n\nWhat I suggest change logic of bisecting to something like\n\n\n      git config bisect.reachable true\n\n\nThis behaviour will reduce bisecting only to reachable commits between\nbad/good points and will never goes away.\n\nMaybe if commit will be found at merge commit git bisect can suggest\nopen another round trip to looking into not reachable way, but anyway\nit should be explicit confirmed by user.\n\n\nBTW, if bad commit is merge point with more than 2 parents, how git\nbisect will find \"first wrong commit\" at the current state?\n\n\nThanks for the attention,\n\n\nOleg\n"},{"id":"292540","messageId":"xmqqinvonwxc.fsf@gitster.mtv.corp.google.com","threadId":"42958","inReplyTo":"CABEd3j8VLbpeWbA6BfHYp5aLPEy0PesqYoHM9u4OM=b7Qm=LDg@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-07-29T18:03:59Z","receivedAt":"2016-07-29T18:04:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oleg Taranenko <olegtaranenko@gmail.com> writes:\n\n> What I suggest change logic of bisecting to something like\n>\n>       git config bisect.reachable true\n\nSuch a configuration should not be needed.\n\nWhen a history with this shape is given to \"git bisect\":\n\n    ----o---o---X---Y---B\n         \\     /\n          o---G\n\nand you gave G as good, and B as bad, it is a BUG that needs to be\nfixed if bisect strayed outside G, X, Y and B.  Setting your new\nconfiguration to false would mean \"please run a buggy version of\nbisect\", which does not make much sense, I would think.\n\n\n\n\n\n"},{"id":"292666","messageId":"CABEd3j-MW--YSC9=nwcgHzxd6cqmUY+ky3-wLxMiMmbBGsvS7Q@mail.gmail.com","threadId":"42958","inReplyTo":"xmqqinvonwxc.fsf@gitster.mtv.corp.google.com","subject":"Re: git bisect for reachable commits only","fromName":"Oleg Taranenko","fromEmail":"olegtaranenko@gmail.com","sentAt":"2016-07-31T00:06:55Z","receivedAt":"2016-07-31T00:07:18Z","isPatch":false,"sender":{"key":"olegtaranenko@gmail.com","avatar":"https://gravatar.com/avatar/016106c4926412cef4141b2d7cea4378aef44db0ca56c9462a5f4a71c7a80955?d=mp&s=160"},"body":"Hi Junio,\n\nThanks for reply.\nLet consider two pretty similar use cases.\n\n************ SCENARIO 1 ************\n\nmkdir bisect\ncd bisect/\ngit init\ngit touch coffee\ngit commit -am \"create coffee\"\ngit branch develop\necho sugar >> coffee\ngit commit -am \"add sugar\" # we are still in master branch\ngit checkout develop       # get back to coffe without sugar\ngit touch tee              # cooking tee in develop branch\ngit commit -am \"tee\"\ngit merge master           #\ncat coffee                 # after merge coffe has sugar\nex +g/sugar/d -cwq coffee  # introducing 'bug' by removing sugar from coffee\ngit commit -am \"merged/amended\" --amend       # the history is amended\necho \"sugar\" >> tee\ngit commit -am \"sugar for tee\"              # just advance for measure\n\n# -------------- We are getting following state ------------------\ngit status                 # develop branch\ngit log --full-history --graph --pretty=oneline\n* 83e9577b4a5d553fdc16806fdea9757229ea9222 sugar for tee\n*   23a4aa69a9d5c03aa145844005555b7ee00c4d63 merged/amended\n|\\\n| * 4c1caf7cb2417181c035a953afdf2389dd130aef add sugar\n* | c080fb4df39d721e2f2e0fdd91fe16d8bdd77515 tee\n|/\n* 3c3043b7d0a0d260c78db55b565f26e430aa5c80 create coffee\n\ncat coffee # nothing                        # discovering coffee has no sugar\ngit checkout 4c1c                           # but we remember it should to have\ncat coffee                                  # ...\"sugar\"\n\ngit bisect start\ngit bisect good\ngit bisect bad develop   # 23a4\ncat coffee               # nothing\ngit bisect bad           # c080\ncat coffee               # nothing\ngit bisect bad           #\nc080fb4df39d721e2f2e0fdd91fe16d8bdd77515 is the first bad commit\ncommit c080fb4df39d721e2f2e0fdd91fe16d8bdd77515\nAuthor: Oleg Taranenko <olegtaranenko@gmail.com>\nDate:   Fri Jul 29 09:08:47 2016 +0200\n\n    tee\n\n:000000 100644 0000000000000000000000000000000000000000\ne69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A tee\n\n\n\nWe are getting first bad commit c080, but git bisect fails.\nWe remember is was introduced in the 23a4 commit via wrong merge and\nhistory amending.\n\n\n************ SCENARIO 2 ************\ncd ..\nmkdir bisect2\ncd bisect2\ngit init\ngit touch coffee\ngit commit -am \"create coffee\"\necho sugar >> coffee\n# we are still in master branch\ngit commit -am \"add sugar\"\ngit branch develop\necho milk >> coffee\ngit commit -am \"add milk to coffee\"\n\n# get back to coffe without sugar\ngit checkout  develop\nex \"+g/sugar/d\" -cwq coffee\necho milk >> coffee\ngit commit -am \"coffee: replace sugar with milk\"\n# cooking tee in develop branch\ngit touch tee\ngit commit -am \"tee\"\ngit checkout master\ngit merge develop\n\n\n#Here we are getting real conflict\ncat coffee\n#<<<<<<< HEAD\n#sugar\n#=======\n#>>>>>>> develop\n#milk\n\n#resolving\ngit checkout develop --theirs -- coffee\ncat coffee             # milk\ngit commit -am \"conflict resolved\"\necho \"sugar\" >> tee\ngit commit -am \"sugar for tee\"              # just advance for measure\n\n\n ---------- State -----------------\ngit log --full-history --graph --pretty=oneline\n* b88a3cb3df58fc018d635d559d212707e953f84d sugar for tee\n*   138824139c0237fe05419d4f40a693e4c19405a3 conflict resolved\n|\\\n| * e1ddbfe05d632d6f12dd7ff9d9b61475c2cde867 tee\n| * ddfb5188c98b8fc803a036ac4eee0610e2bba53f coffee: replace sugar with milk\n* | 0e1c55363e5b2fb04a6072fa470f90770b3eee22 add milk to coffee\n|/\n* 465d0c68c597f1534c3c1e19ed9a086c5da190ae add sugar\n* 24b73ce9085a6d411c06c08cca0536dc8f2239c7 create coffee\n\n\ncat coffee      # only milk, no sugar... bug\ngit checkout 792d\ncat coffee                 # OK, milk & sugar\ngit bisect start\ngit bisect good\ngit bisect bad master      # e1dd\ncat coffee                 # milk only\ngit bisect bad             # ddfb\ncat coffee                 # milk only\ngit bisect bad             # first bad commit !!\n\nIt happens, git really found that somebody (me) was replaced sugar\nwith milk, because ancestor of both branches already has sugar, and\ncommit ddfb\nexplicit removes it.\n\nAs we can see, both strategies can coexisting, and now I ever can't\nstate for sure, which one is more intuitive correct.\n\nI think if repo has relative straight history, more productive to use\nbisect with auto search in un-reachable commits.\nFor messy repositories (especially, with lots of aliens code) more\nsafe to use --reachable bisecting strategy.\n\nThen, I suggest as well additional to defaulting via 'git config\nbisect.reachable true/false' use per bisect session switch\n\n    git bisect start --[un-]reachable-commits # which will override\ndefault setting\n\n\nThanks you for reading to this point,\n\nOleg\n\nOn Fri, Jul 29, 2016 at 8:03 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Oleg Taranenko <olegtaranenko@gmail.com> writes:\n>\n>> What I suggest change logic of bisecting to something like\n>>\n>>       git config bisect.reachable true\n>\n> Such a configuration should not be needed.\n>\n> When a history with this shape is given to \"git bisect\":\n>\n>     ----o---o---X---Y---B\n>          \\     /\n>           o---G\n>\n> and you gave G as good, and B as bad, it is a BUG that needs to be\n> fixed if bisect strayed outside G, X, Y and B.  Setting your new\n> configuration to false would mean \"please run a buggy version of\n> bisect\", which does not make much sense, I would think.\n>\n>\n>\n>\n>\n"},{"id":"292670","messageId":"2bfd9cf5-a9fa-7650-21e9-9ceb9cc34d8b@gmail.com","threadId":"42958","inReplyTo":"CABEd3j-MW--YSC9=nwcgHzxd6cqmUY+ky3-wLxMiMmbBGsvS7Q@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-07-31T09:26:00Z","receivedAt":"2016-07-31T09:26:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 31.07.2016 o 02:06, Oleg Taranenko pisze:\n\n> Then, I suggest as well additional to defaulting via 'git config\n> bisect.reachable true/false' use per bisect session switch\n> \n>     git bisect start --[un-]reachable-commits # which will override\n> default setting\n\nIsn't `--reachable-commits` the same as existing `--ancestry-path`\noption to `git log` and friends (I wonder if passing log options to\nbisect, that is: `git bisect --ancestry-path ...` would work)?\n\n-- \nJakub Narębski\n\n"},{"id":"292718","messageId":"CABEd3j--sxCwv6fWmNxTtdpgwU0_YKbfiFONX6TsQFZGn79yuQ@mail.gmail.com","threadId":"42958","inReplyTo":"CABEd3j-MW--YSC9=nwcgHzxd6cqmUY+ky3-wLxMiMmbBGsvS7Q@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Oleg Taranenko","fromEmail":"olegtaranenko@gmail.com","sentAt":"2016-08-01T10:02:48Z","receivedAt":"2016-08-01T10:34:52Z","isPatch":false,"sender":{"key":"olegtaranenko@gmail.com","avatar":"https://gravatar.com/avatar/016106c4926412cef4141b2d7cea4378aef44db0ca56c9462a5f4a71c7a80955?d=mp&s=160"},"body":"Guys,\n\nfurther investigation shows, git bisect is broken from its core... really.\nLet consider 3rd a bit more complicated scenario\n\n#cd ..\n#rm -rf bisect3\nmkdir bisect3\ncd bisect3\ngit init\ngit touch coffee\ngit commit -am \"create coffee\"\ngit branch tee\necho sugar >> coffee\ngit commit -am \"add sugar\"  # we are still in master branch\necho \"milk\" >> coffee\ngit commit -am \"milk for coffee\"\nex +g/sugar/d -cwq coffee  # introducing 'bug'\ngit commit -am \"somehow remove sugar\"\necho \"mixing...\" >> coffee\ngit commit -am \"coffee mixing\"\n\ngit checkout tee            # get back to coffee without sugar\ngit touch tee\ngit commit -am \"tee\"\n\ngit branch cocktail\necho \"sugar\" >> tee\ngit commit -am \"sugar for tee\"\necho \"milk\" >> tee\ngit commit -am \"milk for tee\"\necho \"mixing...\" >> tee\ngit commit -am \"tee mixing\"\n\ngit checkout cocktail\ngit touch cocktail\ngit commit -am \"prepare cocktail\"\necho orange >>cocktail\ngit commit -am \"add orange juice\"\necho rum >>cocktail\ngit commit -am \"add rum\"\necho mixing >> cocktail\ngit commit -am \"cocktail mixing\"\ncat cocktail  #orange, rum, mixing\ngit merge tee\ngit merge master\n\ngit touch serve\ngit commit -am \"serving...\"\n\ngit log --full-history --graph --pretty=oneline\n\n* 059adf903a2cbc06fe05dda4c916e2c586907f23 serving...\n*   efc89d5253d3126defc7362c25ef069ae9b43fc7 Merge branch 'master' into cocktail\n|\\\n| * dd41e230a3cac5d51a1e994747ff470e2af03cae coffee mixing\n| * c2a44672f1197f34e04cd0fd66434a2b286b574e somehow remove sugar\n| * f50352cfb6bc4a237b73c95ed7ebca074603ae11 milk for coffee\n| * 79b253b316cdc3668697afe473610e35b453ab2f add sugar\n* |   2d626eb5cfaa40a4503be58a5ed27f1ececa6d02 Merge branch 'tee' into cocktail\n|\\ \\\n| * | 7aba690c6c6f73f1906871c9dbf9737ec11a152b tee mixing\n| * | eca611a93697359ec7a52f4a045461180bc365c3 milk for tee\n| * | 7d6844724d0e81751ec1a67c1ffdf0d0fb932350 sugar for tee\n* | | 6754e816922989d5870ec3452437bbbe6aca4d0f cocktail mixing\n* | | 5cbbf0f0882c497590838b163210db3a393b647e add rum\n* | | b46d7d8a361daae382fbef7acabda5416d23da46 add orange juice\n* | | e571fdd09582e40fc54ffc5a4f112eac2b9f2c8e prepare cocktail\n|/ /\n* | 041a5a53704bccc60c489f8c9a4742bad79d5a95 tee\n|/\n* a52a4fa6770d000a9f4e9e297739a6dc88c0cc50 create coffee\n\nAs you can see, no tricks with amended history, but...\n\ngit bisect start HEAD 79b2\nBisecting: 8 revisions left to test after this (roughly 3 steps)\n[6754e816922989d5870ec3452437bbbe6aca4d0f] cocktail mixing\ncat coffee\ngit bisect bad\nBisecting: 2 revisions left to test after this (roughly 1 step)\n[e571fdd09582e40fc54ffc5a4f112eac2b9f2c8e] prepare cocktail\ngit bisect bad\nBisecting: 0 revisions left to test after this (roughly 0 steps)\n[041a5a53704bccc60c489f8c9a4742bad79d5a95] tee\ngit bisect bad\n041a5a53704bccc60c489f8c9a4742bad79d5a95 is the first bad commit\ncommit 041a5a53704bccc60c489f8c9a4742bad79d5a95\nAuthor: Oleg Taranenko <olegtaranenko@gmail.com>\nDate:   Mon Aug 1 10:53:52 2016 +0200\n\n    tee\n\n:000000 100644 0000000000000000000000000000000000000000\ne69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A tee\n\ngit bisect ever not looked into the path where good commit is\ndeclared. Instead it found somehow most common ancestor from whole\ntree (a52a create coffee),  assume it is GOOD commit (why !?) and\ncheck only ^1 (not ^2) parent commit for testing as a potential bug\ncommit.\nNo wonder now, I got a disaster result, looking in my heavy enterprise\nrepository.\n\nCan somebody take care of this issue?\n\nThanks, Oleg\n\nOn Sun, Jul 31, 2016 at 2:06 AM, Oleg Taranenko <olegtaranenko@gmail.com> wrote:\n> Hi Junio,\n>\n> Thanks for reply.\n> Let consider two pretty similar use cases.\n>\n> ************ SCENARIO 1 ************\n>\n> mkdir bisect\n> cd bisect/\n> git init\n> git touch coffee\n> git commit -am \"create coffee\"\n> git branch develop\n> echo sugar >> coffee\n> git commit -am \"add sugar\" # we are still in master branch\n> git checkout develop       # get back to coffe without sugar\n> git touch tee              # cooking tee in develop branch\n> git commit -am \"tee\"\n> git merge master           #\n> cat coffee                 # after merge coffe has sugar\n> ex +g/sugar/d -cwq coffee  # introducing 'bug' by removing sugar from coffee\n> git commit -am \"merged/amended\" --amend       # the history is amended\n> echo \"sugar\" >> tee\n> git commit -am \"sugar for tee\"              # just advance for measure\n>\n> # -------------- We are getting following state ------------------\n> git status                 # develop branch\n> git log --full-history --graph --pretty=oneline\n> * 83e9577b4a5d553fdc16806fdea9757229ea9222 sugar for tee\n> *   23a4aa69a9d5c03aa145844005555b7ee00c4d63 merged/amended\n> |\\\n> | * 4c1caf7cb2417181c035a953afdf2389dd130aef add sugar\n> * | c080fb4df39d721e2f2e0fdd91fe16d8bdd77515 tee\n> |/\n> * 3c3043b7d0a0d260c78db55b565f26e430aa5c80 create coffee\n>\n> cat coffee # nothing                        # discovering coffee has no sugar\n> git checkout 4c1c                           # but we remember it should to have\n> cat coffee                                  # ...\"sugar\"\n>\n> git bisect start\n> git bisect good\n> git bisect bad develop   # 23a4\n> cat coffee               # nothing\n> git bisect bad           # c080\n> cat coffee               # nothing\n> git bisect bad           #\n> c080fb4df39d721e2f2e0fdd91fe16d8bdd77515 is the first bad commit\n> commit c080fb4df39d721e2f2e0fdd91fe16d8bdd77515\n> Author: Oleg Taranenko <olegtaranenko@gmail.com>\n> Date:   Fri Jul 29 09:08:47 2016 +0200\n>\n>     tee\n>\n> :000000 100644 0000000000000000000000000000000000000000\n> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A tee\n>\n>\n>\n> We are getting first bad commit c080, but git bisect fails.\n> We remember is was introduced in the 23a4 commit via wrong merge and\n> history amending.\n>\n>\n> ************ SCENARIO 2 ************\n> cd ..\n> mkdir bisect2\n> cd bisect2\n> git init\n> git touch coffee\n> git commit -am \"create coffee\"\n> echo sugar >> coffee\n> # we are still in master branch\n> git commit -am \"add sugar\"\n> git branch develop\n> echo milk >> coffee\n> git commit -am \"add milk to coffee\"\n>\n> # get back to coffe without sugar\n> git checkout  develop\n> ex \"+g/sugar/d\" -cwq coffee\n> echo milk >> coffee\n> git commit -am \"coffee: replace sugar with milk\"\n> # cooking tee in develop branch\n> git touch tee\n> git commit -am \"tee\"\n> git checkout master\n> git merge develop\n>\n>\n> #Here we are getting real conflict\n> cat coffee\n> #<<<<<<< HEAD\n> #sugar\n> #=======\n> #>>>>>>> develop\n> #milk\n>\n> #resolving\n> git checkout develop --theirs -- coffee\n> cat coffee             # milk\n> git commit -am \"conflict resolved\"\n> echo \"sugar\" >> tee\n> git commit -am \"sugar for tee\"              # just advance for measure\n>\n>\n>  ---------- State -----------------\n> git log --full-history --graph --pretty=oneline\n> * b88a3cb3df58fc018d635d559d212707e953f84d sugar for tee\n> *   138824139c0237fe05419d4f40a693e4c19405a3 conflict resolved\n> |\\\n> | * e1ddbfe05d632d6f12dd7ff9d9b61475c2cde867 tee\n> | * ddfb5188c98b8fc803a036ac4eee0610e2bba53f coffee: replace sugar with milk\n> * | 0e1c55363e5b2fb04a6072fa470f90770b3eee22 add milk to coffee\n> |/\n> * 465d0c68c597f1534c3c1e19ed9a086c5da190ae add sugar\n> * 24b73ce9085a6d411c06c08cca0536dc8f2239c7 create coffee\n>\n>\n> cat coffee      # only milk, no sugar... bug\n> git checkout 792d\n> cat coffee                 # OK, milk & sugar\n> git bisect start\n> git bisect good\n> git bisect bad master      # e1dd\n> cat coffee                 # milk only\n> git bisect bad             # ddfb\n> cat coffee                 # milk only\n> git bisect bad             # first bad commit !!\n>\n> It happens, git really found that somebody (me) was replaced sugar\n> with milk, because ancestor of both branches already has sugar, and\n> commit ddfb\n> explicit removes it.\n>\n> As we can see, both strategies can coexisting, and now I ever can't\n> state for sure, which one is more intuitive correct.\n>\n> I think if repo has relative straight history, more productive to use\n> bisect with auto search in un-reachable commits.\n> For messy repositories (especially, with lots of aliens code) more\n> safe to use --reachable bisecting strategy.\n>\n> Then, I suggest as well additional to defaulting via 'git config\n> bisect.reachable true/false' use per bisect session switch\n>\n>     git bisect start --[un-]reachable-commits # which will override\n> default setting\n>\n>\n> Thanks you for reading to this point,\n>\n> Oleg\n>\n> On Fri, Jul 29, 2016 at 8:03 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Oleg Taranenko <olegtaranenko@gmail.com> writes:\n>>\n>>> What I suggest change logic of bisecting to something like\n>>>\n>>>       git config bisect.reachable true\n>>\n>> Such a configuration should not be needed.\n>>\n>> When a history with this shape is given to \"git bisect\":\n>>\n>>     ----o---o---X---Y---B\n>>          \\     /\n>>           o---G\n>>\n>> and you gave G as good, and B as bad, it is a BUG that needs to be\n>> fixed if bisect strayed outside G, X, Y and B.  Setting your new\n>> configuration to false would mean \"please run a buggy version of\n>> bisect\", which does not make much sense, I would think.\n>>\n>>\n>>\n>>\n>>\n"},{"id":"292750","messageId":"xmqqoa5cl9i7.fsf@gitster.mtv.corp.google.com","threadId":"42958","inReplyTo":"2bfd9cf5-a9fa-7650-21e9-9ceb9cc34d8b@gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-01T16:49:36Z","receivedAt":"2016-08-01T17:05:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narębski <jnareb@gmail.com> writes:\n\n> Isn't `--reachable-commits` the same as existing `--ancestry-path`\n> option to `git log` and friends (I wonder if passing log options to\n> bisect, that is: `git bisect --ancestry-path ...` would work)?\n\nYes, I somehow missed it, but you are absolutely correct to point\nout that what is being requested is --ancestry-path.\n\nMy gut feeling is that by default the command should be taught to\nfollow the ancestry path, but I say this with reservation, as I am\nnot sure offhand what it means to traverse along the ancestry path\nwhen there are multiple good commits.\n\nThanks.\n"},{"id":"292754","messageId":"CAP8UFD118RdB5dX2-wEm5VnKud7sirHhdC9kvWmXV0eAQHvfsA@mail.gmail.com","threadId":"42958","inReplyTo":"CABEd3j--sxCwv6fWmNxTtdpgwU0_YKbfiFONX6TsQFZGn79yuQ@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-08-01T15:41:35Z","receivedAt":"2016-08-01T17:19:44Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Aug 1, 2016 at 12:02 PM, Oleg Taranenko <olegtaranenko@gmail.com> wrote:\n> Guys,\n>\n> further investigation shows, git bisect is broken from its core... really.\n> Let consider 3rd a bit more complicated scenario\n>\n> #cd ..\n> #rm -rf bisect3\n> mkdir bisect3\n> cd bisect3\n> git init\n> git touch coffee\n\ngit touch is not a git command\n\n> git commit -am \"create coffee\"\n\nyou need to \"git add coffee\" first otherwise it doesn't work\n\n> git branch tee\n> echo sugar >> coffee\n> git commit -am \"add sugar\"  # we are still in master branch\n> echo \"milk\" >> coffee\n> git commit -am \"milk for coffee\"\n> ex +g/sugar/d -cwq coffee  # introducing 'bug'\n> git commit -am \"somehow remove sugar\"\n> echo \"mixing...\" >> coffee\n> git commit -am \"coffee mixing\"\n>\n> git checkout tee            # get back to coffee without sugar\n> git touch tee\n\ngit touch is not a git command\nit might be an alias you have that does `touch \"$@\" && git add \"$@\"`\n\n> git commit -am \"tee\"\n>\n> git branch cocktail\n> echo \"sugar\" >> tee\n> git commit -am \"sugar for tee\"\n> echo \"milk\" >> tee\n> git commit -am \"milk for tee\"\n> echo \"mixing...\" >> tee\n> git commit -am \"tee mixing\"\n>\n> git checkout cocktail\n> git touch cocktail\n> git commit -am \"prepare cocktail\"\n> echo orange >>cocktail\n> git commit -am \"add orange juice\"\n> echo rum >>cocktail\n> git commit -am \"add rum\"\n> echo mixing >> cocktail\n> git commit -am \"cocktail mixing\"\n> cat cocktail  #orange, rum, mixing\n> git merge tee\n> git merge master\n>\n> git touch serve\n> git commit -am \"serving...\"\n>\n> git log --full-history --graph --pretty=oneline\n>\n> * 059adf903a2cbc06fe05dda4c916e2c586907f23 serving...\n> *   efc89d5253d3126defc7362c25ef069ae9b43fc7 Merge branch 'master' into cocktail\n> |\\\n> | * dd41e230a3cac5d51a1e994747ff470e2af03cae coffee mixing\n> | * c2a44672f1197f34e04cd0fd66434a2b286b574e somehow remove sugar\n> | * f50352cfb6bc4a237b73c95ed7ebca074603ae11 milk for coffee\n> | * 79b253b316cdc3668697afe473610e35b453ab2f add sugar\n> * |   2d626eb5cfaa40a4503be58a5ed27f1ececa6d02 Merge branch 'tee' into cocktail\n> |\\ \\\n> | * | 7aba690c6c6f73f1906871c9dbf9737ec11a152b tee mixing\n> | * | eca611a93697359ec7a52f4a045461180bc365c3 milk for tee\n> | * | 7d6844724d0e81751ec1a67c1ffdf0d0fb932350 sugar for tee\n> * | | 6754e816922989d5870ec3452437bbbe6aca4d0f cocktail mixing\n> * | | 5cbbf0f0882c497590838b163210db3a393b647e add rum\n> * | | b46d7d8a361daae382fbef7acabda5416d23da46 add orange juice\n> * | | e571fdd09582e40fc54ffc5a4f112eac2b9f2c8e prepare cocktail\n> |/ /\n> * | 041a5a53704bccc60c489f8c9a4742bad79d5a95 tee\n> |/\n> * a52a4fa6770d000a9f4e9e297739a6dc88c0cc50 create coffee\n>\n> As you can see, no tricks with amended history, but...\n>\n> git bisect start HEAD 79b2\n> Bisecting: 8 revisions left to test after this (roughly 3 steps)\n> [6754e816922989d5870ec3452437bbbe6aca4d0f] cocktail mixing\n> cat coffee\n> git bisect bad\n\nWhy is it bad?\nIs it because there is no sugar?\nIn this case you are searching for a commit that removed sugar.\n\n> Bisecting: 2 revisions left to test after this (roughly 1 step)\n> [e571fdd09582e40fc54ffc5a4f112eac2b9f2c8e] prepare cocktail\n> git bisect bad\n> Bisecting: 0 revisions left to test after this (roughly 0 steps)\n> [041a5a53704bccc60c489f8c9a4742bad79d5a95] tee\n> git bisect bad\n> 041a5a53704bccc60c489f8c9a4742bad79d5a95 is the first bad commit\n> commit 041a5a53704bccc60c489f8c9a4742bad79d5a95\n> Author: Oleg Taranenko <olegtaranenko@gmail.com>\n> Date:   Mon Aug 1 10:53:52 2016 +0200\n>\n>     tee\n>\n> :000000 100644 0000000000000000000000000000000000000000\n> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A tee\n>\n> git bisect ever not looked into the path where good commit is\n> declared. Instead it found somehow most common ancestor from whole\n> tree (a52a create coffee),  assume it is GOOD commit (why !?)\n\nYes, and the reason is that all the ancestors of a good commit are\nconsidered good.\nThat's because git bisect supposes that there is only one transition\nfrom good to bad.\nOtherwise we would need a more complex algorithm to find all the\ntransitions from good to bad, and that is not generally needed.\n\n> and\n> check only ^1 (not ^2) parent commit for testing as a potential bug\n> commit.\n> No wonder now, I got a disaster result, looking in my heavy enterprise\n> repository.\n>\n> Can somebody take care of this issue?\n\nI haven't looked at your previous issue much, sorry I have been busy these days.\n"},{"id":"292781","messageId":"xmqq7fc0jmhx.fsf@gitster.mtv.corp.google.com","threadId":"42958","inReplyTo":"CAP8UFD118RdB5dX2-wEm5VnKud7sirHhdC9kvWmXV0eAQHvfsA@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-01T19:51:54Z","receivedAt":"2016-08-01T19:52:37Z","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> Yes, and the reason is that all the ancestors of a good commit are\n> considered good.\n> That's because git bisect supposes that there is only one transition\n> from good to bad.\n> Otherwise we would need a more complex algorithm to find all the\n> transitions from good to bad, and that is not generally needed.\n\nIt may be debatable if that is generally needed or not, but by\ndefinition \"bisect\" is about having a history that has a SINGLE\npoint that changes from good to bad (or old to new, or \"have sugar\"\nto \"no sugar\"), and that single-ness is what allows us to BIsect the\ngraph.  So even if it may be a good thing to have to be able to find\nmultiple transitions, that is outside the scope of how the current\n\"git bisect\" was designed to be used.\n\n> I haven't looked at your previous issue much, sorry I have been busy these days.\n\nI think the \"previous issue\" was that we can ask the user to ask to\ncheck one of 'x' or 'y' when given Good and Bad points in a graph like\nthis:\n\n        x---y---y---o---B\n         \\         / \n          x---G---o\n\nwhile a more natural expectation by a user would be that we only\nneed to check one of these two 'o'.\n\nThinking about it again, I actually think it makes sense to ask the\nuser to check 'y'; there is no good reason to believe that 'y' can\nnever have introduced the badness we are hunting for, and limiting\nthe search to --ancestry-path (which is to ask only for 'o') would\nstop at the merge 'o' if one of the 'y' were bad, which would\nprevents us from knowing the exact breakage.\n\nThere however is no excuse if we asked to check 'x', though.  They\nare ancestors of a Good commit, and \"git bisect\" should be able to\nassume they are Good.\n\n\n\n"},{"id":"292785","messageId":"CAP8UFD315CgntwYiC9g-R7KN0XiL9635Vwv_y8yi4n-uj8o90A@mail.gmail.com","threadId":"42958","inReplyTo":"xmqq7fc0jmhx.fsf@gitster.mtv.corp.google.com","subject":"Re: git bisect for reachable commits only","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-08-01T20:36:06Z","receivedAt":"2016-08-01T20:37:22Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Christian Couder <christian.couder@gmail.com> writes:\n>\n>> Yes, and the reason is that all the ancestors of a good commit are\n>> considered good.\n>> That's because git bisect supposes that there is only one transition\n>> from good to bad.\n>> Otherwise we would need a more complex algorithm to find all the\n>> transitions from good to bad, and that is not generally needed.\n>\n> It may be debatable if that is generally needed or not, but by\n> definition \"bisect\" is about having a history that has a SINGLE\n> point that changes from good to bad (or old to new, or \"have sugar\"\n> to \"no sugar\"), and that single-ness is what allows us to BIsect the\n> graph.  So even if it may be a good thing to have to be able to find\n> multiple transitions, that is outside the scope of how the current\n> \"git bisect\" was designed to be used.\n\nYeah, this is a better version of what I wanted to say.\n\n>> I haven't looked at your previous issue much, sorry I have been busy these days.\n>\n> I think the \"previous issue\" was that we can ask the user to ask to\n> check one of 'x' or 'y' when given Good and Bad points in a graph like\n> this:\n>\n>         x---y---y---o---B\n>          \\         /\n>           x---G---o\n>\n> while a more natural expectation by a user would be that we only\n> need to check one of these two 'o'.\n\nYeah, I reproduced the steps described in the Google Groups discussion:\n\nhttps://groups.google.com/forum/#!topic/git-users/v3__t42qbKE\n\nand I think that is indeed the \"previous issue\".\n\n> Thinking about it again, I actually think it makes sense to ask the\n> user to check 'y'; there is no good reason to believe that 'y' can\n> never have introduced the badness we are hunting for, and limiting\n> the search to --ancestry-path (which is to ask only for 'o') would\n> stop at the merge 'o' if one of the 'y' were bad, which would\n> prevents us from knowing the exact breakage.\n\nI agree.\n\n> There however is no excuse if we asked to check 'x', though.  They\n> are ancestors of a Good commit, and \"git bisect\" should be able to\n> assume they are Good.\n\nI think it does. When I reproduced the steps in the \"previous issue\",\nit did assume they are good.\n"},{"id":"292812","messageId":"xmqqwpk0f5jr.fsf@gitster.mtv.corp.google.com","threadId":"42958","inReplyTo":"CAP8UFD315CgntwYiC9g-R7KN0XiL9635Vwv_y8yi4n-uj8o90A@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-01T23:11:36Z","receivedAt":"2016-08-01T23:11:59Z","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>> I think the \"previous issue\" was that we can ask the user to ask to\n>> check one of 'x' or 'y' when given Good and Bad points in a graph like\n>> this:\n>>\n>>         x---y---y---o---B\n>>          \\         /\n>>           x---G---o\n>>\n>> while a more natural expectation by a user would be that we only\n>> need to check one of these two 'o'.\n>\n> Yeah, I reproduced the steps described in the Google Groups discussion:\n>\n> https://groups.google.com/forum/#!topic/git-users/v3__t42qbKE\n>\n> and I think that is indeed the \"previous issue\".\n>\n>> Thinking about it again, I actually think it makes sense to ask the\n>> user to check 'y'; there is no good reason to believe that 'y' can\n>> never have introduced the badness we are hunting for, and limiting\n>> the search to --ancestry-path (which is to ask only for 'o') would\n>> stop at the merge 'o' if one of the 'y' were bad, which would\n>> prevents us from knowing the exact breakage.\n>\n> I agree.\n\nHaving agreed on that, there are cases where you do want to stop at\nthe merge 'o' on the upper history, when lower-history leading to B\nis the mainline and you are interested in finding the merge with\nwhich side branch introduced a breakage, and not particularly\ninterested in finding the exact commit on the side branch.  Upon\nfinding the merge 'o' that is the parent of 'B' is bad, you find out\nthe owner of the side branch merged there who wrote the two 'y's,\nand have him work on figuring out where in his branch he broke it.\n\nFor that, the --ancestry-path is a wrong way to traverse; what we\nwant in that context is the --first-parent traversal.\n\n>> There however is no excuse if we asked to check 'x', though.  They\n>> are ancestors of a Good commit, and \"git bisect\" should be able to\n>> assume they are Good.\n>\n> I think it does. When I reproduced the steps in the \"previous issue\",\n> it did assume they are good.\n\nI actually had an impression that the original report claimed that\nthe user was asked to check immediate parent of G, and that would be\na bug.\n"},{"id":"292824","messageId":"CABEd3j_6DNgs1u5AdkkzWt7U=J2fZ4a-2jewVjkfExt0KPvWiQ@mail.gmail.com","threadId":"42958","inReplyTo":"xmqqwpk0f5jr.fsf@gitster.mtv.corp.google.com","subject":"Re: git bisect for reachable commits only","fromName":"Oleg Taranenko","fromEmail":"olegtaranenko@gmail.com","sentAt":"2016-08-02T10:15:06Z","receivedAt":"2016-08-02T10:23:31Z","isPatch":false,"sender":{"key":"olegtaranenko@gmail.com","avatar":"https://gravatar.com/avatar/016106c4926412cef4141b2d7cea4378aef44db0ca56c9462a5f4a71c7a80955?d=mp&s=160"},"body":"Guys,\n\nthanks for discussion, I will try to reply in bulk here.\nFirst, assuming the common ancestor is GOOD based on the fact that\nsome descendant given as GOOD is pretty bad idea.\nIt may be, but may not be. In the git-flow like workflows new features\n(aka branches) are created from trunk (master/develop/...)\nsporadically,\nbut later they will mutual merging. I would say more probably they\nhave not common base, then have.\n\nSecond, I don't ask \"create a new algorithm to find all transition\nfrom good/old to bad/new\", not nesessary. If programmer feels\nsomething\nsuspicious, he/she can create another bisect session with narrowed commit range.\n\nThird, testing of any specific commit can be very expensive operation.\nIn my case - shutdown servers/refresh dbs/clean/rebuild in\neclipse/running servers/dropping browser cache/running app in\nbrowser/going through some pages/view UI.\nSome of steps of course are automated, but some not. Anyway I spend\n5-10 min for every iteration. So knowing what commit is bad or good is\nvery valuable, then I'm very interested to hunt the bug-introduced\ncommit with minimal count of testing.\n\nScenario 4 (I will keep my previous mail numbering for possible later reference)\n                 z1----z2---z3\n                /     /      \\\n    G----x1----x2----/---x3---x4--B\n          \\         /   /\n           y1--y2--y3--y4\n\nThis is the happy straight case with closed DAG (hehe, git for\nscientists) between given G good and B bad commits.\nIdeal bisect will check first the shortest way between G & B:\nx1/x2/x3/x4. Let name first-bug commit we are really hunting H and\ncurrent first-bug candidate as h.\nIf h == x1 or x2 -> stop, found\nIf h == x3, bisect will try to test y2/y3/y4 path only\nIf h == x4, bisect will select shortest path z1/z2 (keeping in mind,\nthat x2 is already tested and is good)\n  If h == z1 - found\n  if h == z2 - looking in path y1/y2/y3\n\nScenario 5.\n              v1-------v2\n             /          \\\n        w1--/---w2-------w3---------w4--w5\n       /   /   /                         \\\n      /   /   /            z1----z2---z3  \\\n     /   /   /            /     /      \\   \\\n    C3--C2--C1--G--x1----x2----/---x3---x4--x5--x6--B\n                    \\         /   /\n                     y1--y2--y3--y4\n\nUnhappy case, we have side branches which may introduce bug behaviour,\nwe need to look it through to figure out why it was done, what problem\nwas solved for that and so on.\nLet looking in shortest path x1-x6. If h == x1..x4 - happy use case of\nscenario 4. If discover that h == x5, we are forgetting about z/y\npaths, but first we looking for nearest common commit (C1). As far as\nwe agree that currently is not clear when the new feature was\nintroduced we need to explicit check commit C1 whether it contains a\nfeature we are hunting bug up.\nif C1 is good then pretty possible bad transition was happend in w2-w5\ncommits. Else (C1 is bad) assume that there is no transition from good\nto bad, then assume H == x5 (stop)\nif C1 is good and h == w4/w5 => stop,\n  else if h == w3, new roundtrip, forgetting about w1 commit(not\ninteresting), testing C2, if bad - stop H == w3, if good, v1/v2\ncommits are to test.\n  else if h == w2, forgetting C2 testing, just testing C3. If bad,\nstop, H == w3, if good, w1 to test.\n\nUsing this approach we can safe working with ever octopus merging\n(personally I'm not using, but why not)\n\n\nScenario 6.\n                    z1---z2---z3\n                   /    /       \\\n    C1--G--x1----x2----/------x3 |\n     \\      \\         /         \\|\n      \\      y1--y2--y3--y4--y5--y6--B\n       \\              \\         /|\n        \\              w1--w2-w3 |\n         \\                      /\n          v1------------------v2\n\nImportant note. Before start every side circuit based on common\nancestor user should be explicitly warned, that this is not just\nordinal intermediate bisect commit testing, but possible new round\ntrips with new commit/steps counts\nFor example, if current shortest path is x1-x6, bisect should say\nabout only 6 commits (3 after bisect), not calculating commits in\nother paths.\nReaching node decision, bisect will stay and prompt for testing new\ncommon ancestor with clear instructions what happens, if it will be\ngood or bad, (new unchecked commits and new left bisect steps, in case\ngood and stop or switch to other path in case of octopus).\n\nI have another request to get git bisect more user-friendly, regarding\nrolling back last step or steps, if accidentally 'git bisect bad' or\n'good' was wrong entered, but I think it worth for another thread.\n\n\nCheers, Oleg\n"},{"id":"292849","messageId":"CAGZ79kbx-eq=NPMYon5MV_T5cqiFmcZ_F6zGQO5p7mgLg8bQ4A@mail.gmail.com","threadId":"42958","inReplyTo":"CABEd3j_6DNgs1u5AdkkzWt7U=J2fZ4a-2jewVjkfExt0KPvWiQ@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-08-02T17:25:26Z","receivedAt":"2016-08-02T17:28:20Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 2, 2016 at 3:15 AM, Oleg Taranenko <olegtaranenko@gmail.com> wrote:\n> Guys,\n>\n> thanks for discussion, I will try to reply in bulk here.\n> First, assuming the common ancestor is GOOD based on the fact that\n> some descendant given as GOOD is pretty bad idea.\n> It may be, but may not be. In the git-flow like workflows new features\n> (aka branches) are created from trunk (master/develop/...)\n> sporadically,\n> but later they will mutual merging. I would say more probably they\n> have not common base, then have.\n\ngit bisect has the underlying assumption that the BUG is not there initially\nand introduced by one specific commit, and continues to be there until B.\nWith this assumption you can do a binary search, which allows searching\nin O(log n), which is optimal for the number of iterations needed.\n\n>\n> Second, I don't ask \"create a new algorithm to find all transition\n> from good/old to bad/new\", not nesessary. If programmer feels\n> something\n> suspicious, he/she can create another bisect session with narrowed commit range.\n>\n> Third, testing of any specific commit can be very expensive operation.\n> In my case - shutdown servers/refresh dbs/clean/rebuild in\n> eclipse/running servers/dropping browser cache/running app in\n> browser/going through some pages/view UI.\n> Some of steps of course are automated, but some not. Anyway I spend\n> 5-10 min for every iteration. So knowing what commit is bad or good is\n> very valuable, then I'm very interested to hunt the bug-introduced\n> commit with minimal count of testing.\n\n\nAs you point out each iteration is a burden to the user, so they should be\nkept to a minimum.\n\n>\n> Scenario 4 (I will keep my previous mail numbering for possible later reference)\n>                  z1----z2---z3\n>                 /     /      \\\n>     G----x1----x2----/---x3---x4--B\n>           \\         /   /\n>            y1--y2--y3--y4\n>\n> This is the happy straight case with closed DAG (hehe, git for\n> scientists) between given G good and B bad commits.\n> Ideal bisect will check first the shortest way between G & B:\n> x1/x2/x3/x4. Let name first-bug commit we are really hunting H and\n> current first-bug candidate as h.\n> If h == x1 or x2 -> stop, found\n> If h == x3, bisect will try to test y2/y3/y4 path only\n> If h == x4, bisect will select shortest path z1/z2 (keeping in mind,\n> that x2 is already tested and is good)\n>   If h == z1 - found\n>   if h == z2 - looking in path y1/y2/y3\n\n* git is agnostic of the workflow, i.e. it doesn't know the notion of\ntopic branches or such.\n* What is the worst case in you strategy?\n  (h=y4 means 7 tests by the user IIUC)\n\nGiven the assumptions as laid out above such that we are able to\ndo a binary search, the ideal candidate for scenario 4 is\ny4 or z3 as these split the set of commits to be investigated into\n2 equally sized sets of ancestors and non-ancestors.\n\nWhen a specific workflow is given, it may make sense to weight\ncommits differently. Also some people asked for a strategy that only\nchecks merge commits first, as there are far fewer merge commits and\nthese generally are used for introducing a new feature or refactoring.\n"},{"id":"292865","messageId":"xmqqinvidgyo.fsf@gitster.mtv.corp.google.com","threadId":"42958","inReplyTo":"CABEd3j_6DNgs1u5AdkkzWt7U=J2fZ4a-2jewVjkfExt0KPvWiQ@mail.gmail.com","subject":"Re: git bisect for reachable commits only","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-02T21:00:15Z","receivedAt":"2016-08-02T21:00:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Oleg Taranenko <olegtaranenko@gmail.com> writes:\n\n> First, assuming the common ancestor is GOOD based on the fact that\n> some descendant given as GOOD is pretty bad idea.\n\nWhat you claim is fundamentally incompatible with the way \"bisect\"\nworks as a O(log(n)) operation.  It is likely that your definition\nof Good for the purpose of your bug-hunting needs to be rethought if\nyou want to take advantage of \"bisect\".\n\n> I have another request to get git bisect more user-friendly, regarding\n> rolling back last step or steps, if accidentally 'git bisect bad' or\n> 'good' was wrong entered, but I think it worth for another thread.\n\nAre you aware that you can check $GIT_DIR/BISECT_LOG and replay it\nto recreate any previous state of the bisection?  That would\nprobably help.\n"},{"id":"293152","messageId":"CABEd3j9J-fULWygXnSR0oY9g_m0vWukjAE4aeb6QmiQ1u5FOyw@mail.gmail.com","threadId":"42958","inReplyTo":"xmqqinvidgyo.fsf@gitster.mtv.corp.google.com","subject":"Re: git bisect for reachable commits only","fromName":"Oleg Taranenko","fromEmail":"olegtaranenko@gmail.com","sentAt":"2016-08-04T23:29:32Z","receivedAt":"2016-08-04T23:29:48Z","isPatch":false,"sender":{"key":"olegtaranenko@gmail.com","avatar":"https://gravatar.com/avatar/016106c4926412cef4141b2d7cea4378aef44db0ca56c9462a5f4a71c7a80955?d=mp&s=160"},"body":"On Tue, Aug 2, 2016 at 11:00 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Oleg Taranenko <olegtaranenko@gmail.com> writes:\n>\n>> First, assuming the common ancestor is GOOD based on the fact that\n>> some descendant given as GOOD is pretty bad idea.\n>\n> What you claim is fundamentally incompatible with the way \"bisect\"\n> works as a O(log(n)) operation.  It is likely that your definition\n> of Good for the purpose of your bug-hunting needs to be rethought if\n> you want to take advantage of \"bisect\".\n\nWithout context it sounds a bit silly, agree. Context was, maybe not\nexplicit stated, based on previous discussion:\n\nIf we looking in direct path G..B, of course bisect should show its\npower O(log(n));\nBUT, assuming that any predecessor (G~1/G~2...)...is good if this\ncommit G~n has direct path to B,  but not via G, (as git does now) is\nwrong.\nThis is my concern. Ever G~1 may have not feature we are looking for,\nthen we must treated it as BAD in current git bisect session. To be\nsure we require additional evidence and just opening a new bisect\nroundrips in case G~n is GOOD.\nIf G~n confirmed as BAD, we need to stop looking in this path (no need\nto find transition BAG -> BAD) and switch to another possible common\nancestor (or next octopus parent)\nIn merge-based development (opposite to rebased one) this can happen very easy\n\n\n>> I have another request to get git bisect more user-friendly, regarding\n>> rolling back last step or steps, if accidentally 'git bisect bad' or\n>> 'good' was wrong entered, but I think it worth for another thread.\n>\n> Are you aware that you can check $GIT_DIR/BISECT_LOG and replay it\n> to recreate any previous state of the bisection?  That would\n> probably help.\n\ngit bisect log / replay is not convenient. First we need to find place\nwhere to keep log file (not forget its name), then edit it. If I'm not\nsure how many steps I did a mistake the troubles doubles,\nWhat are obstacles to implement git bisect back ?\nor git bisect back --steps=2\nI don't think it will be significant change in code.\n\nIt would be a great help especially if hunting in multiply logically\nloose-coupled repos. Say searching bug in application, possible caused\nelusive changes on several dependent libraries.\n"}]}