Lovely article.

You’ll also need to approach this guide with an open-mind. If you start off angry or feel like this is an attack on you for using (and maybe even enjoying!) GitHub, then you should come back once you’re in a better headspace. This is merely a detailed guide on how to achieve a solid set of feature parity between GitHub and SourceHut.

I didn’t feel attacked at all till I read this, ironically. The rest of the article made me go right back to feeling unattacked.

Another alternative, I’ve been looking at is radicle. It’s private repository stuff is rough, but public repository stuff, much less so. Seems to be early days but I really like what the project is doing.

Notice: sr.ht is currently in alpha, and the quality of the service may reflect that.

Are these all different services? Seems like quite a hassle. Like a split of project resources.

An alpha classification doesn’t spark confidence in using it productively and for significant projects.

I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.

This is dumb. I have followed the simple 12 step process to set up git send-email and it was so much more hassle than creating an account on GitHub or Codeberg or whatever, and in the end the UX is much worse.

Unfortunately, I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.

After opening with a need to be open-minded, this seems quite close-minded. Sure, it’s their article. Still, I was hoping for a more neutral and substantiated advocating and description.

I certainly didn’t feel like it answered [all] my questions and concerns in multiple sections.

I somewhat like the idea of being able to submit issues via email directly. It does cost on spam classification and prevention, though. An account is easily classifiable as an additional confidence metric. E-Mail, not so much, or with significantly more complexity in relating data and ensuring continuity of source.

An account is a very obvious way to build a reputation. If you see a new GitHub account submitting a PR vs someone having contributed for a long time and significant projects in the same technology, you may approach the reviews quite differently. It is, at least, a very useful and simple way to classify authors and patch submitters.

What does SourceHut provide in this aspect? To what degree does it verify incoming emails authenticity, sender source, and continuity of source hoster? To what degree does it relate information by email address? I assume it does not.

Just a reminder that as long as you don’t need any kind of platform hosting or complex multi-user setup, git itself works fine on a remote machine as your server, even just on LAN. (As always, just setup an ssh key on the two machines so ssh commands are secure and don’t require passwords all the time)

> cd /my/repos
> ssh [email protected] ‘mkdir /home/user/repos/new_repo.git && cd $_ && git init --bare’
> git clone [email protected]:/home/user/repos/new_repo.git

Why Not Use…?

I am aware that there are many other git “forge” platforms available. Gitea, Codeberg, and Forgejo all come to mind. Those platforms are great as well. If you prefer those options instead of SourceHut that’s fine! Switching to any of those would still be a massive improvement over GitHub.

Unfortunately, I find the need to have an account in order to contribute to projects a deal breaker. It causes too much friction for no real gain. Email based workflows will always reign supreme. It’s the OG of code contributions.

Ive been using codeberg(a public forgejo) and it felt more familiar coming from github/gitlab. Sourcehut wasn’t bad, but it did feel quite a bit different and i admittedly didn’t get too far past that. I do like the idea of contributing without an account though. i know that it’s a git feature to create a patch file but having a forge support it is neat.

Semi related, I do look forward to federation of forgejo which i think helps the “needing an account” somewhat. I think it’s less unreasonable to expect someone to have an account on -any federated forge- than to have an account at the specific forge my project is on.

Good article though. It did help make sourcehut make more sense than the first time i looked at it