Hacker News Reader

Comment by rvz | Hacker News Reader

A great time to consider self-hosting your Git repositories then?

Like all the inflated hype in the news with the federation 'goobledegook' and 'technobabble' with Mastodon and alternatives with techies spinning up instances, perhaps it is about time that techies use Git properly and consider self-hosting your repositories just like how many techies do with self-hosting Mastodon instances?

I don't think there is an excuse to continue using GitHub or a centralized provider that can easily be censored by governments or GitHub themselves censoring other repositories via its ToS either way; when developers of GNOME, Wireguard, Redox, etc are already able to self-host their own code on their websites.

If they can self-host their own code and federated networks, you (techies) can also do it too.

View on HN

Except moving your repo is a matter of changing the origin, pushing and notifying your co workers. It's not like moving social network identity, and it saves some admin burden.

If you use just the repo feature, that is. If you fall into the trap of using GitHub's other services you have vendor lock in and you're more screwed than when considering moving from Twitter to Mastodon.

Your instructions would only apply to a dead repo. Migrating an active repo is going to require coordination, dry runs, validation, and planning coupled with updates across your integrations. If you rewrite any history, all bets are off. You're also not taking into account any cleanup activities like reflog expire, or gc prune.

I would also argue that moving to a self hosted remote is going to have significant administrative burden when it comes to security and updates compared to anything SaaS.

Most people use GitHub, GitLab, and Bitbucket for the collaboration features, everyone already knows they can run vanilla git and actively choose not to.

> updates across your integrations

That's already vendor lock in - you're using GitHub's CI pipeline? You're locked.

If I have to update my Jenkins server because I moved from one Git provider to another, I have to point my existing integrations to my new git provider. That's the opposite of being locked in, and just a fact of the matter.

That sounds like it's your Jenkins server not GitHub's.

Yes, it's an integration the repo and users rely on. Any integration that is using a specific git URI will need to be updated. This means new keys, access tokens, and configurations within the integration will need to be updated. That's not a simple process.

> when developers of GNOME, Wireguard, Redox, etc are already able to self-host their own code on their websites

Yeah, but most of us are not developers of them. It often takes less than an hour to self-host Git/Mastodon/Email/DNS or anything else (most of which have ready to use Docker images anyway) that we tend to centralize, but they come with huge maintenance cost (time, money, backups, security, etc).

I self-host my web sites because that's something I actually want to maintain and have more control over. I will leave the rest to the experts because even us "(technies)" easily mess things up.

I already self-host my code (git.captnemo.in), but that doesn't lessen the impact of me browsing a repo on GH, and failing to use GitHub's functionality (viewing previews).

Reply on news.ycombinator.com