{"thread":{"id":"19992","subject":"git bisect; is there a way to pick only from the children of a given commit","startedAt":"2009-07-01T17:12:16Z","lastAt":"2009-07-03T04:42:35Z","messageCount":6,"participants":["Robert Stonehouse","Johannes Schindelin","Sean Estabrooks","Jakub Narebski","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117304","messageId":"loom.20090701T170535-707@post.gmane.org","threadId":"19992","inReplyTo":null,"subject":"git bisect; is there a way to pick only from the children of a given commit","fromName":"Robert Stonehouse","fromEmail":"rstonehouse@solarflare.com","sentAt":"2009-07-01T17:12:16Z","receivedAt":"2009-07-01T17:12:16Z","isPatch":false,"sender":{"key":"rstonehouse@solarflare.com","avatar":null},"body":"Hi,\n\nI had a problem where I thought git bisect would be a good way forwards.\nIt didn't work as expected so I made myself a simpler test-case.\n\nfeatureA (which was a new build target) was broken at HEAD. It had been\ndeveloped on the featureA branch. After featureA was merged into master,\nfeatureB (which had branched from master at the same point as featureA) was\nmerged with master.\n\n $ git log --graph --abbrev-commit --pretty=oneline\n * b394c57... master4\n * 7e8d675... Merge branch 'featureB'\n |\\ \n | * 8d87aee... featureB2\n | * c1a8450... featureB1\n * | 44c5601... master3\n * | 269602a... Merge branch 'featureA'\n |\\ \\ \n | * | 91b1bbb... featureA2\n | * | 0c15834... featureA1\n | |/ \n * | 1ea4a0c... master2\n |/ \n * 204f839... master1\n\nTag featureA1 was my good commit, and HEAD was the bad.\nI was surprised that git bisect was asking me to test commits on the featureB\nbranch. I couldn't test the build target that was broken on branch featureB\nbecause it wasn't present in the code at that point.\n\nI understand that bisect can choose anywhere from the list of commits that are\nincluded in the ancestry of HEAD but excludes commits in the ancestry of \nfeatureA1\n $ git rev-list --pretty=oneline featureA1..HEAD\n b394c57d13c11ce5bec63b4e3556ea9a308bc196 master4\n 7e8d675bb277849d7aaa5c8333f5916455bc3a8a Merge branch 'featureB'\n 44c5601dbc4c3988553999098cd29fe2bddc2f77 master3\n 8d87aee0793a96f9d606fd33cb32b337a2e0a518 featureB2\n 269602a2c5326e475866355986b5dc47f8945b30 Merge branch 'featureA'\n c1a8450e552370cc4efc2ea3bf20bf8456051999 featureB1\n 1ea4a0c51d59ff6471f43e1cb19e207b95baef8a master2\n 91b1bbbbac551cf315bf6e5e8f7cea988fe8d9e8 featureA2\n\nWhat I really want to bisect is the list of commits that are children of\nfeatureA1 (or alternatively any commit that have an ancestor of featureA1)\ni.e. featureA2, master{3,4}, merge{A,B}\n\n $ git rev-list --pretty=oneline --first-parent featureA1..HEAD \nis nearly what I want but I haven't found an option in git-bisect to pass\nextra arguments to rev-list. But also --first-parent wouldn't consider\nfeatureA2 in this case.\n\nIs there a way to do what I want (bisect all children of a commit)?\n\nI hope that this description isn't too unreadable!\nMany thanks\n\n-- \nRob Stonehouse\n"},{"id":"117311","messageId":"alpine.DEB.1.00.0907012058290.4773@pacific.mpi-cbg.de","threadId":"19992","inReplyTo":"loom.20090701T170535-707@post.gmane.org","subject":"Re: git bisect; is there a way to pick only from the children of a given commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-07-01T18:59:34Z","receivedAt":"2009-07-01T18:59:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 1 Jul 2009, Robert Stonehouse wrote:\n\n> featureA (which was a new build target) was broken at HEAD. It had been \n> developed on the featureA branch. After featureA was merged into master, \n> featureB (which had branched from master at the same point as featureA) \n> was merged with master.\n\nWhy don't you just mark the merge commit that introduced featureA as bad, \nthen?\n\nCiao,\nDscho\n"},{"id":"117312","messageId":"BLU0-SMTP20683A1D7E5DEC1370D496AE2E0@phx.gbl","threadId":"19992","inReplyTo":"loom.20090701T170535-707@post.gmane.org","subject":"Re: git bisect; is there a way to pick only from the children of a given commit","fromName":"Sean Estabrooks","fromEmail":"seanlkml@sympatico.ca","sentAt":"2009-07-01T19:22:51Z","receivedAt":"2009-07-01T19:22:51Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 1 Jul 2009 17:12:16 +0000 (UTC)\nRobert Stonehouse wrote:\n\n> $ git log --graph --abbrev-commit --pretty=oneline\n> * b394c57... master4\n> * 7e8d675... Merge branch 'featureB'\n> |\\ \n> | * 8d87aee... featureB2\n> | * c1a8450... featureB1\n> * | 44c5601... master3\n> * | 269602a... Merge branch 'featureA'\n> |\\ \\ \n> | * | 91b1bbb... featureA2\n> | * | 0c15834... featureA1\n> | |/ \n> * | 1ea4a0c... master2\n> |/ \n> * 204f839... master1\n> \n> Tag featureA1 was my good commit, and HEAD was the bad.\n> I was surprised that git bisect was asking me to test commits on the featureB\n> branch. I couldn't test the build target that was broken on branch featureB\n> because it wasn't present in the code at that point.\n\nYou can exclude the featureB branch by listing at good. Git will know there\nis no need to test anything on that branch:\n\n$ git bisect start HEAD featureA1 featureB2\n\nHTH,\nSean\n"},{"id":"117316","messageId":"m38wj8w4s1.fsf@localhost.localdomain","threadId":"19992","inReplyTo":"loom.20090701T170535-707@post.gmane.org","subject":"Re: git bisect; is there a way to pick only from the children of a given commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-07-01T20:02:23Z","receivedAt":"2009-07-01T20:02:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Stonehouse writes:\n\n> I had a problem where I thought git bisect would be a good way forwards.\n> It didn't work as expected so I made myself a simpler test-case.\n> \n> featureA (which was a new build target) was broken at HEAD. It had been\n> developed on the featureA branch. After featureA was merged into master,\n> featureB (which had branched from master at the same point as featureA) was\n> merged with master.\n> \n> $ git log --graph --abbrev-commit --pretty=oneline\n> * b394c57... master4\n> * 7e8d675... Merge branch 'featureB'\n> |\\ \n> | * 8d87aee... featureB2\n> | * c1a8450... featureB1\n> * | 44c5601... master3\n> * | 269602a... Merge branch 'featureA'\n> |\\ \\ \n> | * | 91b1bbb... featureA2\n> | * | 0c15834... featureA1\n> | |/ \n> * | 1ea4a0c... master2\n> |/ \n> * 204f839... master1\n> \n> Tag featureA1 was my good commit, and HEAD was the bad.\n> I was surprised that git bisect was asking me to test commits on the featureB\n> branch. I couldn't test the build target that was broken on branch featureB\n> because it wasn't present in the code at that point.\n\nThat is what \"git bisect skip [|...]\" is for.\"\n\n> Is there a way to do what I want (bisect all children of a commit)?\n\nAlso in 'pu' there is refs/replace mechanism, which was intendend\nmainly to \"repair\" un-bisectable history...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"117359","messageId":"4A4CA06B.8090403@solarflare.com","threadId":"19992","inReplyTo":"BLU0-SMTP20683A1D7E5DEC1370D496AE2E0@phx.gbl","subject":"Re: git bisect; is there a way to pick only from the children of a given commit","fromName":"Robert Stonehouse","fromEmail":"rstonehouse@solarflare.com","sentAt":"2009-07-02T11:56:27Z","receivedAt":"2009-07-02T11:56:27Z","isPatch":false,"sender":{"key":"rstonehouse@solarflare.com","avatar":null},"body":"Sean Estabrooks wrote:\n > On Wed, 1 Jul 2009 17:12:16 +0000 (UTC)\n > Robert Stonehouse wrote:\n >> I was surprised that git bisect was asking me to test commits on the \nfeatureB\n >> branch. I couldn't test the build target that was broken on branch \nfeatureB\n >> because it wasn't present in the code at that point.\n >\n > You can exclude the featureB branch by listing at good. Git will \nknow there\n > is no need to test anything on that branch:\n\nIn my toy example it is easy to identify featureB branch as being \nindependent and marking it as good - but in a real repository it would \nbe much harder as they might be many more merges.\n\nI think if I changed my usage of git bisect good and bad to:\n good => build completes\n OR a revision that does not have the new build target\n bad => new build target fails\nthen I think it will converge to the problem commit. So perhaps this was \njust an issue of semantics\n\nThanks for your help\n\n-- \nRob Stonehouse\n"},{"id":"117399","messageId":"200907030642.36314.chriscool@tuxfamily.org","threadId":"19992","inReplyTo":"4A4CA06B.8090403@solarflare.com","subject":"Re: git bisect; is there a way to pick only from the children of a given commit","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-07-03T04:42:35Z","receivedAt":"2009-07-03T04:42:35Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thursday 02 July 2009, Robert Stonehouse wrote:\n>\n> In my toy example it is easy to identify featureB branch as being\n> independent and marking it as good - but in a real repository it would\n> be much harder as they might be many more merges.\n\nAs Jakub said, when the current commit is untestable, \"git bisect skip\" is \nthe most logical command to use.\n\nNow if you have more information than just \"the current commit is \nuntestable\", for example if you know that the current commit is on a side \nbranch that has work unrelated to the breakage you are looking for, and if \nyou know that the branch started from a \"good\" commit, then you can \nuse \"git bisect good\" instead, because you know the commit is good even if \nyou have not tested it.\n\n> I think if I changed my usage of git bisect good and bad to:\n> good => build completes\n> OR a revision that does not have the new build target\n> bad => new build target fails\n> then I think it will converge to the problem commit. So perhaps this was\n> just an issue of semantics\n\nI'd say that it's an issue of information. If you already have the \ninformation that some commits are good before testing them, then you should \nuse \"git bisect good\" even if you can't test them.\n\nBest regards,\nChristian.\n"}]}