{"thread":{"id":"6010","subject":"git bisect with history manipulation","startedAt":"2006-10-23T14:22:41Z","lastAt":"2006-10-23T16:25:27Z","messageCount":8,"participants":["Kalle Pokki","Linus Torvalds","Jakub Narebski","Sean","Catalin Marinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"29716","messageId":"a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com","threadId":"6010","inReplyTo":"a425f86c0610230718i556537dei9a4b2a5fa8d7f003@mail.gmail.com","subject":"git bisect with history manipulation","fromName":"Kalle Pokki","fromEmail":"kalle.pokki@iki.fi","sentAt":"2006-10-23T14:22:41Z","receivedAt":"2006-10-23T14:22:41Z","isPatch":false,"sender":{"key":"kalle.pokki@iki.fi","avatar":null},"body":"Hi,\n\nI'm still pretty new with git, and cannot quite figure out how to use\n\"git bisect\" effectively in this special case: I'm running an embedded\npowerpc board, to which I need about a dozen platform patches in the\nkernel. Originally I made the patches with quilt on top of 2.6.15.4. I\nrecently started using git, and just applied the patches on top of\nv2.6.18. However, the system seems to oops at every boot now. So I did\n\"git branch downgrade && git reset --hard v2.6.15\" and applied my\npatches on top of it to create a starting state similar to what I had\npreviously. There everything is ok.\n\nWanting to try to bisect the kernel versions, I then merged the master\nbranch into the downgrade branch. Then I marked my last platform\ncommit as good, and v2.6.18 as bad. However the bisect algorithm seems\nto group the platform patches near v2.6.18 instead of v2.6.15, since I\ndon't have the platform files in the bisect checkout. And since I\ndon't have the platform files, I can't compile a kernel that would run\non my board.\n\nSo is there any way to insert a few patches to an arbitrary point\nbackwards in time and start bisecting from that to the present time?\nOr am I thinking this somehow all wrong?\n"},{"id":"29718","messageId":"Pine.LNX.4.64.0610230826080.3962@g5.osdl.org","threadId":"6010","inReplyTo":"a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com","subject":"Re: git bisect with history manipulation","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T15:34:40Z","receivedAt":"2006-10-23T15:34:40Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Kalle Pokki wrote:\n> \n> So is there any way to insert a few patches to an arbitrary point\n> backwards in time and start bisecting from that to the present time?\n> Or am I thinking this somehow all wrong?\n\nIt's possible, but you have to do it the patch-application manually at \neach stage, so it's not a lot of fun. I've had to do it for the opposite \nreason: hunting down a bug with \"git bisect\" when there was _another_ \nunrelated bug that I already had fixed, but that made it impossible to \ntest for the first one. Again, in order to see the first one, I did git \nbisect, but then at each stage applied the fix for the second one if \nneeded.\n\nSo what you would do is to simply do the bisect _as_if_ those patches \nweren't there, and then apply the patches on top of the kernel that \"git \nbisect\" suggests. Then (and this is important), when you mark the result \ngood or bad, don't use just \"git bisect good/bad\" - but name explicitly \nthe commit that you applied your patch-series on.\n\n(This gets a bit easier if you instead of actually cherry-picking the \npatches you want to apply, just apply it as a single patch _without_ \ncommitting it - then all your changes will be effectively \"invisible\" to \ngit bisect anyway, and you don't need to do much of anything special, \nexcept do a \"git checkout -f\" to remove the patch before you say \"that was \nbad\" or \"that was good\").\n\nHOWEVER. It's quite possibly easier to just do it the other way: if your \nseries of patches causes problems when rebased on top of a newer kernel, \njust bisect your rebased series itself (at which point it's all a totally \nnormal \"git bisect\", and you don't need to do anything special). It may be \nthat once you see _which_ patch in the series caused problems, you'll \nimmediately say \"Oh, duh, that got mis-merged\" or (perhaps more likely) by \npointing to a particular commit it will point to a certain area that \nchanged and you suddenly realize _why_ the series caused a problem.\n\nSo depending on the problem, you can try two different approaches.\n\nIt might make sense to extend \"git bisect\" with a \"apply this patch at \neach point\" capability, but that doesn't exist right now. If you do end up \ngoing that way, and automate it, please do send the patches out for \ndiscussion.\n\n\t\tLinus\n"},{"id":"29719","messageId":"ehinsa$a7n$1@sea.gmane.org","threadId":"6010","inReplyTo":"Pine.LNX.4.64.0610230826080.3962@g5.osdl.org","subject":"Re: git bisect with history manipulation","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T15:42:25Z","receivedAt":"2006-10-23T15:42:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> So depending on the problem, you can try two different approaches.\n\n[The approaches being: 1) applying patchseries before testing, and marking\nthe commit before applying as good or bad for bisect; 2) rebasing\n(applying) the patch-series on top of current kernel, and bisecting the\nseries]\n\nYou can try yet another approach, namely rebase v2.6.15..v2.6.18 on top of\nyour patch-series applied to v2.6.15, and bisect that.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29720","messageId":"BAYC1-PASMTP01856E85F8D54BE3CBF69EAE000@CEZ.ICE","threadId":"6010","inReplyTo":"a425f86c0610230722r2a0ae473o467d303f915b6c1e@mail.gmail.com","subject":"Re: git bisect with history manipulation","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-23T15:47:38Z","receivedAt":"2006-10-23T15:47:38Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 23 Oct 2006 17:22:41 +0300\n\"Kalle Pokki\" <kalle.pokki@iki.fi> wrote:\n\n> I'm still pretty new with git, and cannot quite figure out how to use\n> \"git bisect\" effectively in this special case: I'm running an embedded\n> powerpc board, to which I need about a dozen platform patches in the\n> kernel. Originally I made the patches with quilt on top of 2.6.15.4. I\n> recently started using git, and just applied the patches on top of\n> v2.6.18. However, the system seems to oops at every boot now. So I did\n> \"git branch downgrade && git reset --hard v2.6.15\" and applied my\n> patches on top of it to create a starting state similar to what I had\n> previously. There everything is ok.\n> \n> Wanting to try to bisect the kernel versions, I then merged the master\n> branch into the downgrade branch. Then I marked my last platform\n> commit as good, and v2.6.18 as bad. However the bisect algorithm seems\n> to group the platform patches near v2.6.18 instead of v2.6.15, since I\n> don't have the platform files in the bisect checkout. And since I\n> don't have the platform files, I can't compile a kernel that would run\n> on my board.\n> \n> So is there any way to insert a few patches to an arbitrary point\n> backwards in time and start bisecting from that to the present time?\n> Or am I thinking this somehow all wrong?\n> \n\nWell, there is no way to insert the patches into the history at an old\npoint so that they're always available at each bisection point in your\nsearch.  The history is immutable.\n\nWhat you will have to do, is apply your patches manually at each\nbisection point before you compile/test.  After testing you'll have\nto remove your manual patches and continue with your next git\nbisect command.  However, there are a few ways that you can make this\neasier to do.\n\nYou could use the Stacked Git utility (which is a Quilt like clone\nbuilt on top of Git) to help you along in this process.  Actually,\nyou may be able to do the same thing with Quilt itself, but i don't\nknow i've never used it.\n\nThat said, i'll try to outline one way to do this that should work\nusing just native Git commands.  The first thing you need to do is\nprepare a git branch based on the first known-good commit that \ncontains all your extra patches.  So:\n\n$ git checkout -b mypatches v2.6.15\n$ patch < patch1\n$ git commit -a\n$ patch < patch2\n$ git commit -a\netc...\n\nThen you can go back to the master branch and start the bisection:\n\n$ git checkout master\n$ git bisect start\n$ git bisect bad\n$ git bisect good v2.6.15\n\nAt which point git will create and move you to a temporary \"bisect\"\nbranch to do your compile/testing.  Now before you compile, you want\nto append your patch series from the branch you prepared earlier, so:\n\n$ git pull . mypatches\n\nNow compile and test.  After you've tested, you will  have to remove\nyour patches from this branch before continuing with the git bisection\nprocess so:\n\n$ git reset --hard ORIG_HEAD\n\nAnd now continue with your bisection, let's assume the first bisection\npoint still didn't work:\n\n$ git bisect bad\n\nWhich will move you to a new bisection point where you can go back to\nthe \"git pull . mypatches\" step to apply your patch series again and\ndo another compile/test.  Continue with this process as needed.\n\nHope that is clear enough,\nSean\n"},{"id":"29722","messageId":"Pine.LNX.4.64.0610230855260.3962@g5.osdl.org","threadId":"6010","inReplyTo":"ehinsa$a7n$1@sea.gmane.org","subject":"Re: git bisect with history manipulation","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-23T15:59:52Z","receivedAt":"2006-10-23T15:59:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 23 Oct 2006, Jakub Narebski wrote:\n> \n> You can try yet another approach, namely rebase v2.6.15..v2.6.18 on top of\n> your patch-series applied to v2.6.15, and bisect that.\n\nOooh. \n\nYeah, it's a great idea, but likely not practical (or even possible).\n\ngit-rebase really wants a linear set of patches to rebase, which you \ndefinitely don't have for that big history. In fact, even if rebase did \nthe full history rebasing, if later history did a merge of an earlier \nthing (ie if the patch-series that you're trying to rebase onto was based \non something that wasn't an \"epoch tip\", but that was in the middle of \nintertwined history), you'd really be screwed.\n\nAlso, let's face it, rebasing isn't _that_ fast. So trying to rebase huge \nswaths of code would be painful as hell, even if it was a nice linear \nseries.\n\nBut yes, for simpler situations, you could try to switch the problem \naround like you suggest.\n\n\t\tLinus\n"},{"id":"29724","messageId":"ehiq2l$lkq$1@sea.gmane.org","threadId":"6010","inReplyTo":"BAYC1-PASMTP01856E85F8D54BE3CBF69EAE000@CEZ.ICE","subject":"Re: git bisect with history manipulation","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-23T16:19:56Z","receivedAt":"2006-10-23T16:19:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sean wrote:\n\n> $ patch < patch1\n\nWe have git-apply for that (sometimes git-am would work on whole\nseries of patches).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"29725","messageId":"tnxlkn73svi.fsf@arm.com","threadId":"6010","inReplyTo":"BAYC1-PASMTP01856E85F8D54BE3CBF69EAE000@CEZ.ICE","subject":"Re: git bisect with history manipulation","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-10-23T16:21:37Z","receivedAt":"2006-10-23T16:21:37Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Sean <seanlkml@sympatico.ca> wrote:\n> On Mon, 23 Oct 2006 17:22:41 +0300\n> \"Kalle Pokki\" <kalle.pokki@iki.fi> wrote:\n>\n>> So is there any way to insert a few patches to an arbitrary point\n>> backwards in time and start bisecting from that to the present time?\n>> Or am I thinking this somehow all wrong?\n[...]\n> You could use the Stacked Git utility (which is a Quilt like clone\n> built on top of Git) to help you along in this process.  Actually,\n> you may be able to do the same thing with Quilt itself, but i don't\n> know i've never used it.\n\nIt's on my todo list to actually add bisect support to StGIT (someone\nsuggested it on the mailing list) but I can't give any estimates about\nwhen this would be done. The idea is that it will only bisect the base\nand push the patches on top of the new tree (at a first though, it\ndoesn't look difficult at all).\n\nOtherwise, use StGIT to manage the patches and the following sequence\nfor bisecting:\n\n$ git bisect start\n$ stg init\n$ stg pick <patch@branch>\n$ stg pick <patch@branch>\n$ ...\n$ stg pop -a\n$ git bisect good v2.6.x\n$ git bisect bad\n$ stg push -a\n$ ... test ...\n$ stg pop -a\n$ git bisect good|bad\n$ stg push -a\n$ ...\n\n-- \nCatalin\n"},{"id":"29726","messageId":"BAYC1-PASMTP110AEA1A20D3DF82D9BCE8AE000@CEZ.ICE","threadId":"6010","inReplyTo":"ehiq2l$lkq$1@sea.gmane.org","subject":"Re: git bisect with history manipulation","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-10-23T16:25:27Z","receivedAt":"2006-10-23T16:25:27Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 23 Oct 2006 18:19:56 +0200\nJakub Narebski <jnareb@gmail.com> wrote:\n\n> Sean wrote:\n> \n> > $ patch < patch1\n> \n> We have git-apply for that (sometimes git-am would work on whole\n> series of patches).\n\nPoint taken.  git-rebase and git-cherrypick may also be appropriate\nto snag the commits from another branch rather than reapplying them\nfrom patches.  In fact you may already have a branch that works\nwhich contains just your patches on top of it.  I was trying to\nmake the example as clear as possible rather than exhaustive.\n\nSean\n"}]}