{"thread":{"id":"22482","subject":"Linux Kernel based project in git","startedAt":"2010-02-02T09:05:24Z","lastAt":"2010-02-06T11:43:36Z","messageCount":4,"participants":["git@eisendle.net","Avery Pennarun","Christian Eisendle","Stephen Kelly"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133340","messageId":"9da7f2802f639777acfeb38eb1e3db90.squirrel@webmail.eisendle.net","threadId":"22482","inReplyTo":null,"subject":"Linux Kernel based project in git","fromName":"","fromEmail":"git@eisendle.net","sentAt":"2010-02-02T09:05:24Z","receivedAt":"2010-02-02T09:05:24Z","isPatch":false,"sender":{"key":"git@eisendle.net","avatar":null},"body":"Hi,\n\nI'm rather new to this mailing list so I hope this is the right place for\nmy question :-)\n\nWe recently moved one of our projects over from SVN to git.\nThis project is basically a Linux BSP for an ARM9 based processor using\nKernel 2.6.22.\n\nFor release we always generate 3 patches:\n- BSP patch\n- USB patch (since USB part is an external patch comming from a 3rd party)\n- WiFi patch (same as for USB)\n\nSo my question is:\nWhat's the best way for handling this inside the git repository?\n\nIMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based on\nunmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the\npatch and for applying possible fixes. BSP branch for actual BSP related\nfeature development and fixes.\nThe changes in these branches are merged into the master branch which is\nused for compiling/testing the whole BSP.\n\nIs this a useful approach or are there other, better ways for generating\nthe three patches and compiling testing the whole thing?\n\nThanks!\nChristian.\n"},{"id":"133382","messageId":"32541b131002021153t53d19e32j56be356c219c5780@mail.gmail.com","threadId":"22482","inReplyTo":"9da7f2802f639777acfeb38eb1e3db90.squirrel@webmail.eisendle.net","subject":"Re: Linux Kernel based project in git","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-02T19:53:13Z","receivedAt":"2010-02-02T19:53:13Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Feb 2, 2010 at 4:05 AM,  <git@eisendle.net> wrote:\n> For release we always generate 3 patches:\n> - BSP patch\n> - USB patch (since USB part is an external patch comming from a 3rd party)\n> - WiFi patch (same as for USB)\n>\n> So my question is:\n> What's the best way for handling this inside the git repository?\n>\n> IMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based on\n> unmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the\n> patch and for applying possible fixes. BSP branch for actual BSP related\n> feature development and fixes.\n> The changes in these branches are merged into the master branch which is\n> used for compiling/testing the whole BSP.\n\nAre you planning to submit these patches upstream at any point?  If\nnot, it might be easiest to just jam them all together in one branch\nand not look back.  Since it seems like they probably affect quite\ndifferent parts of the code, you could always extract a clean set of\npatches *later* and submit those patches upstream.\n\nBut that's just my lazy advice :)  The disadvantage to maintaining\nthem in separate branches is that probably none of the three branches\nwill work on its own anyway, since you don't have a physical device\nthat only has the new USB device, or only the new WiFi device, or only\nneeds the BSP but doesn't have updated USB or WiFi.  Putting them in\nseparate branches is therefore a bit artificial and won't buy you\nmuch.\n\nHave fun,\n\nAvery\n"},{"id":"133450","messageId":"be6731d603701c3c5befc79613fd451b.squirrel@webmail.eisendle.net","threadId":"22482","inReplyTo":"32541b131002021153t53d19e32j56be356c219c5780@mail.gmail.com","subject":"Re: Linux Kernel based project in git","fromName":"Christian Eisendle","fromEmail":"git@eisendle.net","sentAt":"2010-02-03T08:32:18Z","receivedAt":"2010-02-03T08:32:18Z","isPatch":false,"sender":{"key":"git@eisendle.net","avatar":null},"body":"\n>> For release we always generate 3 patches:\n>> - BSP patch\n>> - USB patch (since USB part is an external patch comming from a 3rd\n>> party)\n>> - WiFi patch (same as for USB)\n>>\n>> So my question is:\n>> What's the best way for handling this inside the git repository?\n>>\n>> IMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based\n>> on\n>> unmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the\n>> patch and for applying possible fixes. BSP branch for actual BSP related\n>> feature development and fixes.\n>> The changes in these branches are merged into the master branch which is\n>> used for compiling/testing the whole BSP.\n>\n> Are you planning to submit these patches upstream at any point?  If\n> not, it might be easiest to just jam them all together in one branch\n> and not look back.  Since it seems like they probably affect quite\n> different parts of the code, you could always extract a clean set of\n> patches *later* and submit those patches upstream.\n\nFor BSP I plan to upstream eventually.\n\nThe basic idea was to divide the project in three different patches since\nUSB and WiFi comes from a third party and is not released under GPL (well,\ndifferent story...)\nKeeping them in three different branches would make patch creation easier\nespecially if fixes are checked in into the USB/WiFi branch.\n\n>\n> But that's just my lazy advice :)  The disadvantage to maintaining\n> them in separate branches is that probably none of the three branches\n> will work on its own anyway, since you don't have a physical device\n> that only has the new USB device, or only the new WiFi device, or only\n> needs the BSP but doesn't have updated USB or WiFi.  Putting them in\n> separate branches is therefore a bit artificial and won't buy you\n> much.\n\nAt least the BSP could work on its own but for WiFi and USB you are right -\nit's hard to test them seperately.\nI just thought that there is a convenient way for handling such kind of\nproject.\n\nThanks,\nChristian.\n"},{"id":"133792","messageId":"hkjkl7$8eg$1@ger.gmane.org","threadId":"22482","inReplyTo":"be6731d603701c3c5befc79613fd451b.squirrel@webmail.eisendle.net","subject":"Re: Linux Kernel based project in git","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2010-02-06T11:43:36Z","receivedAt":"2010-02-06T11:43:36Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"Christian Eisendle wrote:\n>>> IMHO it would make sense to have 3 branches (BSP, USB, WiFi) each based\n>>> on\n>>> unmodified 2.6.22 Kernel. USB and WiFi branch is used for generating the\n>>> patch and for applying possible fixes. BSP branch for actual BSP related\n>>> feature development and fixes.\n>>> The changes in these branches are merged into the master branch which is\n>>> used for compiling/testing the whole BSP.\n>>\n>> Are you planning to submit these patches upstream at any point?  If\n>> not, it might be easiest to just jam them all together in one branch\n>> and not look back.  Since it seems like they probably affect quite\n>> different parts of the code, you could always extract a clean set of\n>> patches *later* and submit those patches upstream.\n> \n> For BSP I plan to upstream eventually.\n> \n> The basic idea was to divide the project in three different patches since\n> USB and WiFi comes from a third party and is not released under GPL (well,\n> different story...)\n\nDo you distribute this kernel?\n"}]}