So your primary goal isn't to hide the individual commits, but rather to protect some sensitive information? If your goal in the end is to go open source, perhaps a better solution is to pull those sensitive bits out into another repo which you keep private. You could then pull those in manually, or as a plugin (if you're on rails) or such. The problem with making a "one commit per release" repo is that it really does nothing for the user. If you're not giving them the history, what's the point of putting the code into git for them? You could just as well provide them with direct packages for each version. If you instead provide the full change history (minus the bits you wish to protect) then a repo is a good thing. They can see the whole history, help out where need be (that whole open source thing), and of course each release is found in the repo as a tag.
Tekkub Github General Support Join us on IRC: #github on freenode.net Discussion group: [email protected] http://github.com/tekkub On Thu, Oct 30, 2008 at 7:42 AM, jgeiger <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
