Personal Log »

Self-hosting git repos

I already decided to rely less on GitHub and use GitLab instead, and the truth is that since then I haven’t started many new projects –and I even forgot about GitLab and still made a couple of new repos in GH, :facepalm:–.

GitHub Copilot is now available to everybody and the controversy has gotten worse when they are charging money for the service, including a campaign by Software Freedom Conservancy.

I like Drew’s commentary on Copilot and open source laundering, specially:

[…] I would update your licenses to clarify that incorporating the code into a machine learning model is considered a form of derived work, and that your license terms apply to the model and any works produced with that model.

Which is probably the right thing to do, but we know that if GitHub (actually, Microsoft) have implemented Copilot in the way they have is because they think they can get away with it, so it is likely that adding a notice like that is not going to have any effect.

Anyway, I just re-considered if I need one of these hosting solutions (also known as “forge”), and I got to the conclusion that I don’t.

Self-hosting a git repo over SSH is very easy:

$ mkdir my_repo_name
$ cd my_repo_name
$ git init --bare

Optionally, if you plan to serve the repo over HTTP:

# PWD is still my_repo_name
$ cp hooks/post-update.sample hooks/post-update

And that’s all! You can use myuser@hostname:/path/to/repos/my_repo_name as remote and you have a private repo.

Although you may have a clone somewhere else, remember to set backups and things like that, and you are set.

I also wanted to have a way of browsing the repos via web, because sometimes is useful to not require git or a clone to check the code. I also like the idea of rendering a as HTML to have a small microsite for a project that perhaps doesn’t need a dedicated page on my website.

For that I decided to use cgit, that you can see in action at –very empty, for now–. I also enabled clones over HTTPS (read only), so the repos are public, and all together took me about 15 minutes.

It is clear that I have lost functionality –that I don’t need–, but this is perfect for me because:

  • My projects are small and likely to only interest me.
  • I can do without CI, that arguably would be a waste of resources and energy for such small projects.
  • I have almost never got any contributions, and when I have, the contributors are likely to have the skills to send patches by email (or provide me with a URL to pull). I recommend this tutorial on how to contribute to email driven projects.
  • I can always move to use a forge if the project grows to a point where there is a real benefit. For example, it is likely ubox MSX lib will stay on GitLab.

Obviously there are some benefits that come with centralisation. Besides easier workflows for contribution, discovery is an important one: you search on GitHub for projects.

In my experience, that wasn’t that important for my projects. Most of them got some stars only after I shared a link to the repo on a forum or social media, and for most people it was a way of having bookmark or just say “cool project”. And it really doesn’t matter: I shared the code in case it was useful to somebody else, but if I didn’t have any meaningful contributions, the stars didn’t do anything for me.

Anyway, the bottom line is that anything that is not GitHub won’t have the benefits of being on the most popular hosting service, so I think it won’t matter that much if I use GitLab or if I self-host my repositories.

I know this is just a drop on the ocean, but if we don’t do anything, nothing will ever change.

Would you like to discuss the post? You can send me an email!