3 ms·
Hubber here (same username on github.com). We in GitHub's OSPO have been working on an open source GitHub App to address the use case where organizations want
by ahpook 2y ago
Hubber here (same username on github.com). We in GitHub's OSPO have been working on an open source GitHub App to address the use case where organizations want to keep a private mirror of an upstream public fork so they can review code and remove IP/secrets/keys that get committed and squash history before any of those changes are made public. Getting a beta release this week, in fact - check it out, I'm curious what yall think about the approach
https://github.com/github-community-projects/private-mirrors https://github.com/github-community-projects/private-mirrors
- dttocs 2y agoLooks like a promising tool and workflow to mitigate the risks we are discussing here. If you haven’t already done so, it might help the discussion here if you could highlight how this app deals with the issues outlined. Is the intent of the mirror repo creation that it’s more-or-less equivalent to “git clone —mirror”? I took a quick look at the code, and didn’t see a direct correspondence with “git clone —mirror” when creating the mirror repository.
- ahpook 2y agoThat's correct, it's doing a clone into an empty repo rather than using the fork API - code is here: https://github.com/github-community-projects/private-mirrors/blob/main/src/server/repos/controller.ts#L107 https://github.com/github-community-projects/private-mirrors... As it pertains to the post, since that private mirror is disconnected, none of the concerns about accessing deleted data apply. The downside is that you don't get any of GitHub's performance and UI affordances from the fork network. But for the use case of private iterations on work headed for a public upstream, that's a trade-off that seems worth making.