It partly comes from the history that's in the current git repository, which includes sensitive information that I don't want public. I did this with previous repository and realized that it had put the entire history up, which included access keys, etc. I removed that repository, deleted the .git directory and created a fresh one.
I am working with multiple people, so a centralized server helps with code sharing, and I'd like to keep an internal history, but have a one commit per release strategy. I guess another example would be how to deal with an internal project that you eventually release as open source? You wouldn't want to use the full history to everyone, since it wasn't meant to be public at the time. So when you choose to release it, how do you deal with that? Thanks. On Oct 29, 6:07 pm, "GitHub Support" <[EMAIL PROTECTED]> wrote: > What exactly do you want to do? Are you planning on pushing the private > repo directly to the public one, or do you only want one commit per public > release (tag) in the public repo? If the former, what's the real point of > the private repo... if the latter what's the point of the public repo over > just regular packaged releases? > Tekkub > Github General Support > Join us on IRC: #github on freenode.net > Discussion group: [EMAIL PROTECTED]://github.com/tekkub > > On Wed, Oct 29, 2008 at 4:11 PM, Dustin <[EMAIL PROTECTED]> wrote: > > > On Oct 29, 2:09 pm, jgeiger <[EMAIL PROTECTED]> wrote: > > > I'm trying to find a best practice for hosting a project that needs > > > private development, but also needs the code to be publicly > > > accessible. > > > > I'm thinking about setting up 2 repositories, 1 public, 1 private, > > > doing all the work on the private shared repository, and when creating > > > a "release", copying the code from my local private to my local > > > public, committing and pushing. > > > > Essentially I'm trying to hide the daily internal workflow of the > > > commits and changes while providing a public base that can be > > > controlled for things like database settings, keys, etc. > > > Are branches that get squashed insufficient? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" 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/github?hl=en -~----------~----~----~----~------~----~------~--~---
