Changing the remote doesn't migrate anything in the issue tracker, merge requests, webhooks, pages or wiki

Migrating from GitHub to GitLab

https://www.youtube.com/watch?v=VYOXuOg9tQI

this adresses some of the issues.

It doesn't solve the number one issue: External references to your project will all still point to github.com since that's where the project homepage (aka README.md) is.

If GitHub does get sold to MS and I end up moving to GitLab, I'll probably push one last commit to the GitHub repo adding a header saying the project has moved, with a link to the GitLab repo. It's not perfect, but it wouldn't be too bad.

Until MSFT/GitHub does what Sourceforge.net did - taking over project sites from projects which moved away and adding malware (adware/spyware) into those ;)

(I believe with all critique on Microsoft they aren't as bad, but want to exemplarize the risk)

It might just be cleaner to close the github repo and when other projects find a 404 where it used to be, they'll have to use super detective skills (i.e. Google it) to find the project's new home. And if they can't find it that way, then nothing of value was lost. (Yes, yes, I know it's more nuanced than that, but if you wanted permanence, you'd be hosting on your own domain, right?)

This would be a great way for them to accelerate migration away from Github.

I expect Google could be convinced to accept certain files or metadata in a README as equivalent to a 301 permanent redirect, meaning searches will remain effective. That would account for a lot, especially if Chrome begins to honour it.

Actually, the #1 issue is that everyone can easily file an issue/contribute in other ways at Github without having to create another account to do so.

You can sign in with your Github account to gitlab.com.

I seem to remember that under the GDPR, vendors have to make data exportable. I wonder if people could use that for GitHub issues and the Wiki.

GitHub pages is super easy to move except for getting users to know the new domain.

The GDPR only applies to personal data, which won't be most of the content on GitHub.

Anyway, there are APIs which one can use to export issues.

Personal data is extremely broad and is any data that can be identified to an individual. If my photos are Facebook are personal data, then so is my code on GitHub (even if some people are professional photographers or programmers).

It wouldn't be seamless. But it wouldn't be difficult for a competitor to create a "competitor import" feature that moved over most of it in a few clicks.

It's possible, but I think it's a stretch to say it "wouldn't be difficult."

This is also why I put my documentation in markdown files in the repo instead of using the Github wiki. I knew it would save me hassle later.

Wikis on Github are cloneable as normal repos: just use project.wiki.git instead of project.git in the clone URL.

Still one step too much making it harder to migrate. Should've been a directory in a repo, default to `wiki` or whatever and configurable to something else.

that leads to problems with access control, though.

This means everybody linking to your docs will link to GitHub, thus you have a hard time moving ;)

As opposed to linking to GP's GitHub Wiki?

Agreed on both points. The shift will bring a lot of opportunity to build a more decentralized repo base. I think something like (Keybase)[http://keybase.io] might be interesting.