While I'm no git-guru, personally I'd just git add remote public (your public github url) and when you have an update in your working private repo that you want to push public just do a git push to the public repo. That way they keep the same history as opposed to having to mess with odd merging.
But, like I said, this may be really bad advice. ;) On Mon, Dec 8, 2008 at 10:39, Jon Hancock <[EMAIL PROTECTED]> wrote: > > I am within a few days (I hope) of having a new version of shellshadow > working with the latest merb + dm. The new webapp will be basic but > have a fairly mature user model and tries to use merb and dm as they > are intended. > > My goal is to very quickly after publishing to fork my source and open > source the core app as a merb sample app. I am currently using a > github private repo for shellshadow source and am thinking of forking > this to create the public sample app. > > I would like some opinions on how best to use github to achieve this. > Since I will want to do many incremental releases but want to get a > first version out quickly I'm at a loss for git best practices. > > Should I fork my private repo to the public repo? If I do this, will > git retain some knowledge of the history that will allow me more > efficient updates? Or does it not matter and should I just copy my > full app and create a new public github repo? > > I'm still a very basic git user and would like some advice. > > thanks, Jon > http://shellshadow.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
