I would move the parts that are unique to the private branch out of the versioning system completely. It seems to be a fairly common practice on rails projects I've worked on to not version database.yml at all, since potentially every clone will have a different database setup. The parts you're putting in the application controller could be pulled out to lib and then loaded with an include or require, conditionally if needed. If you do want to keep these files versioned, you could do so in another repo and manually copy them into the paths needed when you clone the public repo.
Tekkub Github General Support Join us on IRC: #github on freenode.net Discussion group: [email protected] http://github.com/tekkub On Mon, Nov 10, 2008 at 9:34 AM, jgeiger <[EMAIL PROTECTED]> wrote: > > 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 [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 -~----------~----~----~----~------~----~------~--~---
