I have created a small tool that automatically mirrors public repos from GitLab to GitHub: https://github.com/grdl/gitlab-mirror-maker

Meaning, a repo can be hosted on GL but still benefit from better exposure and disoverability of GH.

How I usually do it if I want to have my project on Github and Gitlab is configure two push remotes like this:

> git remote set-url --add --push origin <github-remote>

> git remote set-url --add --push origin <gitlab-remote>

This way I have an automatic backup to the second remote.

Does this mean when you `git push origin <branch>` it gets pushed to both remotes? I had no idea you could have two remotes with the same name, neat!

TIL that's exactly what this does, alternatively you can add them all to an 'all' remote, to make it more explicit:

https://jigarius.com/blog/multiple-git-remote-repositories#t...

However, you can add multiple URLs to 'origin' and push to them all at once.

But GitLab already has repo mirroring built-in, what am I missing?

You're not missing anything. It does use GitLab's mirroring API. However, GitLab doesn't have any global mirroring settings, you need to set up each repo individually. The tool just saves you a huge bunch of clicking around and copy pasting auth tokens. Useful if you have a big collection of repos you'd like to mirror. And if you'd like every new public repo to be mirrored automatically.

Pushing from gitlab to another git host is free and in the community edition[1]. Pulling on the other hand is a paid feature.

[1]: https://docs.gitlab.com/13.2/ee/user/project/repository/repo...

If your project is open source on gitlab.com - you get all paid features for free.

Here is a link to our program for open source projects for anyone interested! https://about.gitlab.com/solutions/open-source/ (community advocate at GitLab)

This is awesome! Thanks for sharing.

I suspect due to the sheer number of internal deploys, Gitlab does not always get the exposure warranted.

My work place is switching from internal Gitlab/gitlab-runners to external gitlab.com + internal gitlab-runners. We are very happy with both scenarios, but neither gains Gitlab any exposure.

you can create a merge request as well using only git, gitlab support it

  git push -o merge_request.create 

I have it under alias `gmr`, it will use default branch as a target

And the infinitely handy "push -o ci.variable=ALPHA=BETA" or its friend "push -o ci.skip" to influence the CI job that's created, if any, due to the push

https://docs.gitlab.com/ee/user/project/push_options.html#pu...

That's the first I've read of `push -o`. Does GitHub have push options like that as well?

That's the first I ever heard of it, either, and was unable to find out if those options are exposed more generally to the CI pipeline (so can I make my own "-o" toys?)

I don't recall ever hearing of any such thing in GitHub, and their help search is so atrocious I don't know that I'd be able to find the answer even now. That said, I can't imagine that kind of customization fits into GitHub's mental model, which goes double given that they just recently even _developed_ a CI system to which one could send those options

Can you expand on that scenario, how are you hosting the internal runners? Our gitlab server is quite limited in capacity and that would actually be a cool solution to outsource them onto our bigger servers.

You can install gitlab-runner package on your own machine and register the instance in the Gitlab. It will be seen in the Gitlab panel next to all other runners.

Hugely ironic, but not surprising since projects on GitHub get better exposure and also the ability to raise funds with GitHub sponsors.

This is true and important. But I also have to admit that I like the interface of GH more and I am just used to searching on GH - it always has been like google search for code for me.

GitLab has a dark theme though

I maintain a bunch of docker images that are purposed to run on gitlab ci, they are obviously hosted on github because only github has push-event integrations with docker hub.

I make a push, docker hub builds and publishes the image, the image is only pulled by gitlab ci.

Gitlab is great, but it lacks many popular integrations that must come from not-gitlab.

I imagine that's an oversight of sorts because you could just build the images on gitlab too.

There are ways, but:

1. I need to run gitlab ci myself on my host(s)

2. My host must be logged in to docker hub

3. Gitlab CI must run as privileged container

4. There are more hacks required to let gitlabci build the image and push as me.

on github you just authorize docker-hub to get webhooks from github, and that's it, it does the rest itself.

Can't you build and push via CI?

Too lazy to do the setup on multiple computers

Good point. I just thought it was funny, but it is good to know that there ARE differences other than branding.

The only reason I choose GitHub over Gitlab is the network effect.

If making someone create a new account on Gitlab means they won't contribute to a project, then I'd rather publish it on GitHub instead, even if GitHub is closed-source. The network of GitHub is intrinsic to that website and Gitlab might not ever be able to replicate the size of its userbase. (Of course, if I'm proven wrong I'd migrate.)

Yes, it doesn't help Gitlab to have this mentality, but out of the dozens of OSS repositories I've used only two have come from Gitlab. Every single other one I had originally found on GitHub.

Why would they contribute to this project if they don't have a gitlab account?

They may use self-hosted gitlab at work.

I understand the irony but here's the case where most Gitlab users only have account with their company's self hosted gitlab platform and hence can't contribute to FOSS on Gitlab unless they create another account. I hosted it on Gitlab for OSS visibility and get more users contributing to the project.

lol I was thinking exactly this