Gitlab has introduced a five-user limit for free groups

I'm currently hosting a git repo on my home machine and it's used by me when I'm on the road and a few people I trust enough to have logins on my DMZ machine.

It seems there should be an easy way to use gitlab or github as a public read-only proxy to changes that are released on the private repo. And then going the other way, sucks up PRs from public sites and lovingly integrates them into the "real" repo on my home machine.

Yes. There are security ramifications. There are availability ramifications. I seems slightly to be trying to skirt GitLab's policies they're probably putting into effect to avoid going bankrupt. But the flip-side is I really don't need a wiki or a bug tracker or whatever else GitLab is working on. I would pay a small amount of cash to just get a public repo mirror.

And we all have different ideas about how to make this "easy". I don't mind running scripts on my local host, but would like to avoid polling the public repo to see if someone's posted a PR. I also don't want to have to run a script in a container on the public repo. So would love it if you could set the public repo to proxy PRs to a remote repo.

Just curious if anyone else has similar requirements. Maybe you have a corporate repo and want to mirror it to a public site like GitLab, GitHub or SourceHut. Maybe, like me, *you* just want a remote repo to stash your code but a public location so your home server doesn't melt down that one time someone slashdots your project.

Gitea supports push mirrors.

Gitlab does repo mirroring.

Thx for the response. That might be a solution. I fear that GitLab might notice me doing that and decide they don't like it. But definitely something to play around with. I'll look again on the site and see if I can see where you activate it; didn't see it first time around.

Oh. Hadn't thought of Gitea in a while. Will check it out. Thx for the reply!

Not just push mirrors but pull mirrors and push+pull mirrors. I frequently use the pull mirrors to backup repos that I don't trust to stay around (either because they might break a TOS or be right on the line, or i expect the author to not leave it around for some reason). It's definitely become one of my "must have" for any kind of local hosting stuff esp since the docker images make it basically painless to deploy.

As someone who works at the Co -- If you are within the free usage limits, we are fine with you mirroring a repo on .com.

If you are hosting game binaries or Shrek the 3rd we might have some problems, but if you have a genuine source code project that shouldn't be a problem unless you become a DDoS target.

It’s not that hard to setup. It’s a built-in feature in something like gitea. Or you can write a `git push` cron task or a server hook in git to keep the 2 in sync. GitHub is full of mirror repos. You can also disable issues, discussions, wiki, and pull requests if you don’t want to deal with that.

That's what I'm doing now. It's what I don't want to do. I want the public repo to autopush PRs to my private repo so I don't have to poll it.

[LOL. A previous edit autocorrected "autopush" to "autopsy." Or maybe it was a Freudian slip on my part.]

You can trigger a GitHub action on any PR and run any arbitrary code you want.

Yeah. I don't want to set up docker. I just want the public server to mirror the PR by pushing it to my private server. Launching docker to diff the public mirror against the private server isn't completely out of the question. It just seems "inelegant." But I dislike it less than I dislike the idea of running a cron job on the private server to poll the public server.

Thanks for the suggestion, though. I may go ahead with something like this.

Lol. Yes. Thx for the reply. Definitely real code. I think the closest we come to "media" are a few open source fonts which we're using in accordance w/ the license.

> You can also disable … pull requests

That is the one thing you can’t disable on GitHub unless something changed recently. Very annoying for mirrors where development happens elsewhere.

Make a README.md which clearly states this at the top, and a CONTRIBUTING.md. After that, it's just not your problem if someone opens a PR.

Again. I DON'T want to run a script in a container on github's infrastructure.

There are a couple of other options, although I'll agree that none of them are ideal:

1) You can set up Github Actions to automatically close pull requests: https://github.com/marketplace/actions/close-pull-request

2) You can use "interaction limits" (in repository settings, under "moderation options") to limit repository interactions to collaborators. This can only be set for 6 months at a time, though, so you'll need to reactivate it periodically.

3) You can archive the project and unarchive it temporarily when making changes, disabling all activity on the fork.

If you’re polling, you can use GitHub APIs. They are pretty well documented. If you want a turn-key solution, use gitea. Depending on how flexible you need it, gitea might cover your scenarios. But you can have actions in gitea as well that automate polling GitHub APIs for issues or comments or pull requests etc.

About needing logins on your DMZ machine, that's not necessary if they use SSH keys to access the git user, which has no shell.

You might find it easier to manage those permissions with gitolite if you want to restrict the users to just git access, and to just some repos.

GitHub self hosted runners might address this concern.