New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open source Eigen #11

Closed
orta opened this Issue Dec 25, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@orta
Member

orta commented Dec 25, 2014

https://iphone.artsy.net

  • New repo, we could do the opposite to https://github.com/artsy/force-public, wherein we make our current repo private and use that for time-sensitive, or confidential PRs that need to be private but that we create a new repo ( with maybe even a new history? We'd have to probably crop the history for the private one too, they will leak into public for sure. ) that's public and we migrate over issues / milestones / CI to the public repo and use that from then on in.
  • Existing Repo, read + sanitise all 2k issues, delete PRs leaking information, nuke git history for any file that's ever had a key in it, kill git history and open the current repo. Still create an eigen-private that we can use when something shouldn't be discussed publicly for whatever reason.

@orta orta added the question label Dec 25, 2014

@meejah

This comment has been minimized.

Show comment
Hide comment
@meejah

meejah Dec 25, 2014

I would "git init" a new repo for the public stuff, and developers may add the private stuff as a separate remote if/when you need to merge things in or whatever (add it as "private" or "danger" or something ;)

Doing some basic sanitizing on the private one seems like a good idea as well ("git filter-branch" being your best friend here -- and the tree-filter is a fast way to delete things).

If you remember to always "git merge --squash" when bringing things from private -> public you will reduce your chances of accidentally bringing in a bunch of commits from private that you didn't mean to. "--squash" always makes a new commit.

meejah commented Dec 25, 2014

I would "git init" a new repo for the public stuff, and developers may add the private stuff as a separate remote if/when you need to merge things in or whatever (add it as "private" or "danger" or something ;)

Doing some basic sanitizing on the private one seems like a good idea as well ("git filter-branch" being your best friend here -- and the tree-filter is a fast way to delete things).

If you remember to always "git merge --squash" when bringing things from private -> public you will reduce your chances of accidentally bringing in a bunch of commits from private that you didn't mean to. "--squash" always makes a new commit.

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Dec 25, 2014

Member

Thanks, another idea I had around this was that the main repo could be public, but that our personal forks e.g. orta/eigen or 1aurabrown/eigen are private. Thus a private few PRs could go internal within a fork, and then get released to artsy/eigen & the world when whatever constraints have kept it private are finished.

Member

orta commented Dec 25, 2014

Thanks, another idea I had around this was that the main repo could be public, but that our personal forks e.g. orta/eigen or 1aurabrown/eigen are private. Thus a private few PRs could go internal within a fork, and then get released to artsy/eigen & the world when whatever constraints have kept it private are finished.

@chriseidhof

This comment has been minimized.

Show comment
Hide comment
@chriseidhof

chriseidhof Dec 26, 2014

For objc.io, we have an articles repo and an articles-private. This works really well. But neither one contains "private" information, just things that are not open to the public yet.

For objc.io, we have an articles repo and an articles-private. This works really well. But neither one contains "private" information, just things that are not open to the public yet.

@orta

This comment has been minimized.

Show comment
Hide comment

@orta orta closed this Jan 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment