# git bisect; is there a way to pick only from the children of a given commit 6 messages from 2009-07-01 to 2009-07-03. Participants: Robert Stonehouse, Johannes Schindelin, Sean Estabrooks, Jakub Narebski, Christian Couder. Thread: https://gitlist.dev/t/19992 ## Robert Stonehouse, 2009-07-01 17:12 Subject: git bisect; is there a way to pick only from the children of a given commit Message-ID: URL: https://gitlist.dev/e/loom.20090701T170535-707%40post.gmane.org ``` Hi, I had a problem where I thought git bisect would be a good way forwards. It didn't work as expected so I made myself a simpler test-case. featureA (which was a new build target) was broken at HEAD. It had been developed on the featureA branch. After featureA was merged into master, featureB (which had branched from master at the same point as featureA) was merged with master. $ git log --graph --abbrev-commit --pretty=oneline * b394c57... master4 * 7e8d675... Merge branch 'featureB' |\ | * 8d87aee... featureB2 | * c1a8450... featureB1 * | 44c5601... master3 * | 269602a... Merge branch 'featureA' |\ \ | * | 91b1bbb... featureA2 | * | 0c15834... featureA1 | |/ * | 1ea4a0c... master2 |/ * 204f839... master1 Tag featureA1 was my good commit, and HEAD was the bad. I was surprised that git bisect was asking me to test commits on the featureB branch. I couldn't test the build target that was broken on branch featureB because it wasn't present in the code at that point. I understand that bisect can choose anywhere from the list of commits that are included in the ancestry of HEAD but excludes commits in the ancestry of featureA1 $ git rev-list --pretty=oneline featureA1..HEAD b394c57d13c11ce5bec63b4e3556ea9a308bc196 master4 7e8d675bb277849d7aaa5c8333f5916455bc3a8a Merge branch 'featureB' 44c5601dbc4c3988553999098cd29fe2bddc2f77 master3 8d87aee0793a96f9d606fd33cb32b337a2e0a518 featureB2 269602a2c5326e475866355986b5dc47f8945b30 Merge branch 'featureA' c1a8450e552370cc4efc2ea3bf20bf8456051999 featureB1 1ea4a0c51d59ff6471f43e1cb19e207b95baef8a master2 91b1bbbbac551cf315bf6e5e8f7cea988fe8d9e8 featureA2 What I really want to bisect is the list of commits that are children of featureA1 (or alternatively any commit that have an ancestor of featureA1) i.e. featureA2, master{3,4}, merge{A,B} $ git rev-list --pretty=oneline --first-parent featureA1..HEAD is nearly what I want but I haven't found an option in git-bisect to pass extra arguments to rev-list. But also --first-parent wouldn't consider featureA2 in this case. Is there a way to do what I want (bisect all children of a commit)? I hope that this description isn't too unreadable! Many thanks -- Rob Stonehouse ``` ## Johannes Schindelin, 2009-07-01 18:59 Subject: Re: git bisect; is there a way to pick only from the children of a given commit Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0907012058290.4773%40pacific.mpi-cbg.de In-Reply-To: ``` Hi, On Wed, 1 Jul 2009, Robert Stonehouse wrote: > featureA (which was a new build target) was broken at HEAD. It had been > developed on the featureA branch. After featureA was merged into master, > featureB (which had branched from master at the same point as featureA) > was merged with master. Why don't you just mark the merge commit that introduced featureA as bad, then? Ciao, Dscho ``` ## Sean Estabrooks, 2009-07-01 19:22 Subject: Re: git bisect; is there a way to pick only from the children of a given commit Message-ID: URL: https://gitlist.dev/e/BLU0-SMTP20683A1D7E5DEC1370D496AE2E0%40phx.gbl In-Reply-To: ``` On Wed, 1 Jul 2009 17:12:16 +0000 (UTC) Robert Stonehouse wrote: > $ git log --graph --abbrev-commit --pretty=oneline > * b394c57... master4 > * 7e8d675... Merge branch 'featureB' > |\ > | * 8d87aee... featureB2 > | * c1a8450... featureB1 > * | 44c5601... master3 > * | 269602a... Merge branch 'featureA' > |\ \ > | * | 91b1bbb... featureA2 > | * | 0c15834... featureA1 > | |/ > * | 1ea4a0c... master2 > |/ > * 204f839... master1 > > Tag featureA1 was my good commit, and HEAD was the bad. > I was surprised that git bisect was asking me to test commits on the featureB > branch. I couldn't test the build target that was broken on branch featureB > because it wasn't present in the code at that point. You can exclude the featureB branch by listing at good. Git will know there is no need to test anything on that branch: $ git bisect start HEAD featureA1 featureB2 HTH, Sean ``` ## Jakub Narebski, 2009-07-01 20:02 Subject: Re: git bisect; is there a way to pick only from the children of a given commit Message-ID: URL: https://gitlist.dev/e/m38wj8w4s1.fsf%40localhost.localdomain In-Reply-To: ``` Robert Stonehouse writes: > I had a problem where I thought git bisect would be a good way forwards. > It didn't work as expected so I made myself a simpler test-case. > > featureA (which was a new build target) was broken at HEAD. It had been > developed on the featureA branch. After featureA was merged into master, > featureB (which had branched from master at the same point as featureA) was > merged with master. > > $ git log --graph --abbrev-commit --pretty=oneline > * b394c57... master4 > * 7e8d675... Merge branch 'featureB' > |\ > | * 8d87aee... featureB2 > | * c1a8450... featureB1 > * | 44c5601... master3 > * | 269602a... Merge branch 'featureA' > |\ \ > | * | 91b1bbb... featureA2 > | * | 0c15834... featureA1 > | |/ > * | 1ea4a0c... master2 > |/ > * 204f839... master1 > > Tag featureA1 was my good commit, and HEAD was the bad. > I was surprised that git bisect was asking me to test commits on the featureB > branch. I couldn't test the build target that was broken on branch featureB > because it wasn't present in the code at that point. That is what "git bisect skip [|...]" is for." > Is there a way to do what I want (bisect all children of a commit)? Also in 'pu' there is refs/replace mechanism, which was intendend mainly to "repair" un-bisectable history... -- Jakub Narebski Poland ShadeHawk on #git ``` ## Robert Stonehouse, 2009-07-02 11:56 Subject: Re: git bisect; is there a way to pick only from the children of a given commit Message-ID: <4A4CA06B.8090403@solarflare.com> URL: https://gitlist.dev/e/4A4CA06B.8090403%40solarflare.com In-Reply-To: ``` Sean Estabrooks wrote: > On Wed, 1 Jul 2009 17:12:16 +0000 (UTC) > Robert Stonehouse wrote: >> I was surprised that git bisect was asking me to test commits on the featureB >> branch. I couldn't test the build target that was broken on branch featureB >> because it wasn't present in the code at that point. > > You can exclude the featureB branch by listing at good. Git will know there > is no need to test anything on that branch: In my toy example it is easy to identify featureB branch as being independent and marking it as good - but in a real repository it would be much harder as they might be many more merges. I think if I changed my usage of git bisect good and bad to: good => build completes OR a revision that does not have the new build target bad => new build target fails then I think it will converge to the problem commit. So perhaps this was just an issue of semantics Thanks for your help -- Rob Stonehouse ``` ## Christian Couder, 2009-07-03 04:42 Subject: Re: git bisect; is there a way to pick only from the children of a given commit Message-ID: <200907030642.36314.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200907030642.36314.chriscool%40tuxfamily.org In-Reply-To: <4A4CA06B.8090403@solarflare.com> ``` On Thursday 02 July 2009, Robert Stonehouse wrote: > > In my toy example it is easy to identify featureB branch as being > independent and marking it as good - but in a real repository it would > be much harder as they might be many more merges. As Jakub said, when the current commit is untestable, "git bisect skip" is the most logical command to use. Now if you have more information than just "the current commit is untestable", for example if you know that the current commit is on a side branch that has work unrelated to the breakage you are looking for, and if you know that the branch started from a "good" commit, then you can use "git bisect good" instead, because you know the commit is good even if you have not tested it. > I think if I changed my usage of git bisect good and bad to: > good => build completes > OR a revision that does not have the new build target > bad => new build target fails > then I think it will converge to the problem commit. So perhaps this was > just an issue of semantics I'd say that it's an issue of information. If you already have the information that some commits are good before testing them, then you should use "git bisect good" even if you can't test them. Best regards, Christian. ```