Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Even if, switching your used repo hosting service is a matter of minutes if you're using git. You register on the other site, add your SSH key, update the remote URL of your repository which is just a
git remote set-url origin <new url>and then hitgit push, probably with something like--forceor another option, kinda forgot the exact name. So that's something you could easily automate in like 10 lines of bash script for all your repositories.It's super hard to "trap" people in something like github because git is so open and decentralized. Switching is super easy. Most people who stay on github or gitlab do it because they need the CI/CD pipelines or because they're lazy and/or stupid.
When I read this discussion on HackerNews they act like they're trapped and it would require moving the sun and the earth to switch over.
Yeah sounds like a big nothingburger to me. If you just use gitlab for private projects with basic pushing and pulling without any fancy gitlab features, switching is a matter of minutes.
Now, if you've built your entire company setup around gitlab and use everything they offer, yeah switching is gonna be a lot harder and will require more preparation. However, it's not impossible in the slightest. Even a large corporation with hundreds of developers could make a switch within 2 weeks.
And the open issues, tasks and pull requests?
Right.
Those aren't git features, those are features provided by surrounding tooling, not git itself, so I didn't really consider them. I also never used them in private projects.
However, issues you can migrate easiely. I've seen tools out there that copy the issue content from github and to somewhere new. The creator of that issue is then a bot user or something, but the issue is still there and can be worked on. On github, the bot will leave a message that this issue is now handled somewhere else and closes it. Done.
Pull requests are also simple, you just merge them all. I haven't seen a lot of projects with hundreds of open pull requests that were lying there for weeks or months. Now yes, you will lose the comments and history of the pull request itself, but I don't think that's very important.
Tasks I don't know. I've never used them and don't even know what they do. If it's just a glorified kanban board with plenty of cards that say "Do X", you can just copy paste them to your new tool because there's nothing technical about them.
https://docs.codeberg.org/advanced/migrating-repos/
Those are all part of the forge, not git.
The 2 are very different things.
And what kind of service is gitlab, which we are discussing here, or github which was brought up in the comment, or codeberg?
They are forges.
I think the comment of migrating git, was more for smaller and maybe private projects. Not large collaborations. So only the git part, not the forge part.