{"thread":{"id":"22759","subject":"Branching a subset of your working tree","startedAt":"2010-02-22T21:07:04Z","lastAt":"2010-02-22T21:44:32Z","messageCount":2,"participants":["Ron Garret","Chris Packham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135341","messageId":"ron1-F4D522.13070422022010@news.gmane.org","threadId":"22759","inReplyTo":null,"subject":"Branching a subset of your working tree","fromName":"Ron Garret","fromEmail":"ron1@flownet.com","sentAt":"2010-02-22T21:07:04Z","receivedAt":"2010-02-22T21:07:04Z","isPatch":false,"sender":{"key":"ron1@flownet.com","avatar":null},"body":"What is the recommended way to create a branch that contains a subset of \nyour working tree?  The use case is creating a distribution branch that \nwill be pushed out to a server and I only want to include files that are \nready to be released.\n\nThanks,\nrg\n"},{"id":"135344","messageId":"a038bef51002221344ic966a22x939824fa31020bff@mail.gmail.com","threadId":"22759","inReplyTo":"ron1-F4D522.13070422022010@news.gmane.org","subject":"Re: Branching a subset of your working tree","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2010-02-22T21:44:32Z","receivedAt":"2010-02-22T21:44:32Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Mon, Feb 22, 2010 at 1:07 PM, Ron Garret <ron1@flownet.com> wrote:\n> What is the recommended way to create a branch that contains a subset of\n> your working tree?  The use case is creating a distribution branch that\n> will be pushed out to a server and I only want to include files that are\n> ready to be released.\n>\n> Thanks,\n> rg\n\nWell we did something similar at $dayjob. We had a repository\nconsisting of code we wanted to release under the LGPL and code we\nwanted to keep private.\n\nWe ended up using git filter-branch to create 2 new repositories with\ncommit histories one for the GPL stuff and one for the proprietary\nstuff. We then started working on them as 2 separate repositories.\n\nThis is possibly a different use case for your situation. We were\nhappy to wear the fact that our developers would have to re-clone the\n2 repos but it sounds like you may want to be able to submit common\ncode when it is logically complete.\n\nAnother suggestion would be to use branches instead of separate repos.\nThis similar to how git.git is run. i.e. \"master\" is the stable\nbranch, \"next\" is the proving ground for features that have been\ncooked sufficiently and \"pu\" is where new topics get introduced\n(disclaimer: this may be an inaccurate representation of how git.git\nis _actually_ run but you get the gist). This of course assumes you\nare happy for the unstable code to be visible.\n"}]}