Ok, I've kinda thought about this and it's not that I'm looking to have a public repo without a history, but more like what I'll describe below.
I have a project that is currently in use as a production application and is still being used and revised. I need to release the source code for the project, along with any changes that I make to the source. The private project already has a long commit history that I'm not too concerned about losing, so I'm willing to create a new fresh repository to solve that issue. What I need now is an example/best practice to have a private branch of the project I can use and push to a private repository, and a public branch that I will push to the public repository. I'll be developing on the private branch, including making changes that will need to remain private but also merging the changes into the public branch. (Things like database.yml. I'll have a default version in the public branch, but if I make a change in the private branch, I don't want to have to re-checkout the public version after EVERY merge. This also is a conflict in things like the application.html.erb file where in my private branch I am including analytics tracking, but don't want to have the include merged when I make normal change to the file. (say a css class on a div)) I'm hoping for a way to clean up what is looking to be a big mess on every merge... On Oct 30, 12:42 pm, "GitHub Support" <[EMAIL PROTECTED]> wrote: > 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]://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 github@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
