{"thread":{"id":"17492","subject":"Git setup for kernel in-house development + mainstream submissions?","startedAt":"2009-02-01T21:25:55Z","lastAt":"2009-02-03T04:13:04Z","messageCount":3,"participants":["PaV","Johannes Gilger","Matt Graham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"102784","messageId":"49861363.1000104@aster.pl","threadId":"17492","inReplyTo":null,"subject":"Git setup for kernel in-house development + mainstream submissions?","fromName":"PaV","fromEmail":"pav@aster.pl","sentAt":"2009-02-01T21:25:55Z","receivedAt":"2009-02-01T21:25:55Z","isPatch":false,"sender":{"key":"pav@aster.pl","avatar":null},"body":"Hello,\n\nI would like to kindly ask for suggestions how to setup and use git in a\ncompany that performs in-house kernel development (drivers mostly) for\nits own devices and would like to occasionaly submit patches for mainstream.\n\nI've come up with a short list of use cases/requirements (possibly not\nexhaustive, any suggestions here as well please?):\n\n1) a way to separate development of in-house code (various drivers)\n\n2) a place to merge everything done in-house and provide current\ndevelopment snapshot for internal use\n\n3) something that tracks the current mainstream tree, to be merged with\n(3) ocassionaly (or (2)?)\n\n4) a simple way to select changes (which may be as small as only parts\nof any of the drivers), format them and submit for upstream merge.\nPreferably, if possible, prepare those series of patches and store them\nfor later use (immediate submission might not be possible and might not\nbe done at all).\n\n5) (more?)\n\n\nSo the proposed setup might be:\n(1) - in-house devel could be done on separate branches for each driver\n(2) - a master branch (on the main server) for in-house snapshots and\ndistribution\n(3) - a separate tracking branch for mainstream\n(4) - now this is hard.\nThe main problems are how to create, how to diff and how to manage those\npatches (stgit?) and what to do when mainstream gets updated, etc...\n\nSo ideas are: rebase and/or stgit/quilt. Or/and maybe topic branches,\ncreating new branches for each new kernel version for each driver,\ncopying the old branch and rebasing?\nThis is the most important part for which I'd like to ask for suggestions...\n\nAny other suggestions are of course also welcome, my experience in git\nis small and I might have missed things.\n\nThank you!\nPaul\n"},{"id":"102832","messageId":"gm677g$3io$2@ger.gmane.org","threadId":"17492","inReplyTo":"49861363.1000104@aster.pl","subject":"Re: Git setup for kernel in-house development + mainstream submissions?","fromName":"Johannes Gilger","fromEmail":"heipei@hackvalue.de","sentAt":"2009-02-02T07:26:40Z","receivedAt":"2009-02-02T07:26:40Z","isPatch":false,"sender":{"key":"heipei@hackvalue.de","avatar":"https://avatars.githubusercontent.com/u/6072?v=4"},"body":"On 2009-02-01, PaV <pav@aster.pl> wrote:\n> I would like to kindly ask for suggestions how to setup and use git in a\n> company that performs in-house kernel development (drivers mostly) for\n> its own devices and would like to occasionaly submit patches for mainstream.\n> [...]\n> So the proposed setup might be:\n> (1) - in-house devel could be done on separate branches for each driver\n\nDo you really want to have separate drivers in the same git repository? \nDo these drivers share so much code and depend on each other that this \nwould be necessary? If not I'd suggest you think about separate git \nprojects for each driver, unless there is a compelling reason against \nit.\n\nGreetings,\nJojo\n\n-- \nJohannes Gilger <heipei@hackvalue.de>\nhttp://hackvalue.de/heipei/\nGPG-Key: 0x42F6DE81\nGPG-Fingerprint: BB49 F967 775E BB52 3A81  882C 58EE B178 42F6 DE81\n"},{"id":"102911","messageId":"1c5969370902022013l7c0b3619ue1de39c6d8a13563@mail.gmail.com","threadId":"17492","inReplyTo":"49861363.1000104@aster.pl","subject":"Re: Git setup for kernel in-house development + mainstream submissions?","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2009-02-03T04:13:04Z","receivedAt":"2009-02-03T04:13:04Z","isPatch":false,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"On Sun, Feb 1, 2009 at 16:25, PaV <pav@aster.pl> wrote:\n> I would like to kindly ask for suggestions how to setup and use git in a\n> company that performs in-house kernel development (drivers mostly) for\n> its own devices and would like to occasionaly submit patches for mainstream.\n>\n> 4) a simple way to select changes (which may be as small as only parts\n> of any of the drivers), format them and submit for upstream merge.\n> Preferably, if possible, prepare those series of patches and store them\n> for later use (immediate submission might not be possible and might not\n> be done at all).\n>\n> (4) - now this is hard.\n> The main problems are how to create, how to diff and how to manage those\n> patches (stgit?) and what to do when mainstream gets updated, etc...\n\nWhen you decide what to prepare for an upstream merge, it sounds like\nwhat you'd want to do is make a new \"upstream\" branch and cherry pick\nthe changes you want onto it.  You can use git cherry-pick -n to clean\nthem up or squash them together if necessary.\n"}]}