8 ms·

A beginner's guide to Sourcehut (2025)

60 points by bradley_taunt 5mo ago

topham 5mo ago
If you're major concern is copilot : Microsoft sucking up your codebase, you better not be producing open source applications anywhere. Not a single open source license will protect you. (And it won't help even if they add an exclusion clause for AI).
- dijit 5mo ago
  Hostile forges will help though, unless the forge gets big enough. Scrapers (SEO bots included) tend to only have a handful of "corner cases" built for navigating sites - if your code forge is actively trying to prevent scraping it could help prevent quite a lot. Your choices remain important, even if it's not foolproof.
  - negura 5mo ago
    codeberg serves a poisoned AI page when the detection is triggered
- xbar 5mo ago
  If your only concern is copilot, this is accurate. For Micrsoft-competitive, closed source projects, SourceHub is a much better choice than GitHub.
aniviacat 5mo ago
The author appears to highly appreciate being able to contribute without an account, just an email. I didn't quite get why that is. Isn't an account effectively just an email, with an additional password?
- righthand 5mo ago
  An account would be tied to a users table record as well as a profile, activity log, etc. Git is decentralized but source forges on average are not. I can make a commit to your code if you share the repo, but committing that code under my git user/email doesnt create an account on the source forge.
- xigoi 5mo ago
  Having to create an account adds friction and requires you to agree to shady “terms and conditions”.
musicmatze 5mo ago
One very crucial point that no forge (IIRC) supports that the article missed (or I accidentially skipped it) is that email supports tree-style discussion! That is a HUGE benefit IMHO, especially for patchsets, but also for "issue" discussion!
KolmogorovComp 5mo ago
Patches / PR > It’s probably the core reason developers choose GitHub as their main git forge. I get it. It does have it’s advantages of giving a better experience for reviewing a set of changes. Initially. But what if I told you there was a time when submitting email-based patches was the standard for version control? The author explains well how you can bear with patches, but not why patches were chosen in the first place. What advantages do they have over PR? I see none, and I won't lose my precious time working-around an inferior process to Github's already subpar PR one.
- xigoi 5mo ago
  Patches allow people to contribute without having an account on the forge.
- musicmatze 5mo ago
  You did not explain why the patch based process is "inferior", neither did you explain why you'd have to "work around" the process!
  - mudkipdev 5mo ago
    Learning git format-patch, send-email, configuring SMTP, setting up wrapping, mailing list etiquette, versioned patch sets...
- dapperdrake 5mo ago
  Here is what email patches are all about: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne... I tried email patches with another person myself. The only reason GH won here, is because the git people made one fatal mistake: They forgot to include the tree hash and only show the commit hash in the email patch. But the commit hash is useless. When you email patch, then commits people want to treat as "the same" and talk about have different hashes. The commit times differ and there is not only the commit author, but also the committer. We stopped doing email patches, because commit hashes became useless for communicating with each other. GitHub made commit hashes "constant" in a way people care about. For our purposes, tree hashes would have been much better in practice. The git user interface is literally "git porcelain". It cuts you for no reason.
m4rc3lv 5mo ago
For all the reasons the OP mentions, I am using Coderberg for a while. This is already in European hands - no cloud-act. https://codeberg.org/ https://codeberg.org/

60 points by bradley_taunt 5mo ago

If you're major concern is copilot : Microsoft sucking up your codebase, you better not be producing open source applications anywhere. Not a single open source license will protect you. (And it won't help even if they add an exclusion clause for AI).

dijit 5mo ago
Hostile forges will help though, unless the forge gets big enough. Scrapers (SEO bots included) tend to only have a handful of "corner cases" built for navigating sites - if your code forge is actively trying to prevent scraping it could help prevent quite a lot. Your choices remain important, even if it's not foolproof.
- negura 5mo ago
  codeberg serves a poisoned AI page when the detection is triggered
xbar 5mo ago
If your only concern is copilot, this is accurate. For Micrsoft-competitive, closed source projects, SourceHub is a much better choice than GitHub.

aniviacat 5mo ago

The author appears to highly appreciate being able to contribute without an account, just an email. I didn't quite get why that is. Isn't an account effectively just an email, with an additional password?

righthand 5mo ago
An account would be tied to a users table record as well as a profile, activity log, etc. Git is decentralized but source forges on average are not. I can make a commit to your code if you share the repo, but committing that code under my git user/email doesnt create an account on the source forge.
xigoi 5mo ago
Having to create an account adds friction and requires you to agree to shady “terms and conditions”.

musicmatze 5mo ago

One very crucial point that no forge (IIRC) supports that the article missed (or I accidentially skipped it) is that email supports tree-style discussion! That is a HUGE benefit IMHO, especially for patchsets, but also for "issue" discussion!

KolmogorovComp 5mo ago

Patches / PR > It’s probably the core reason developers choose GitHub as their main git forge. I get it. It does have it’s advantages of giving a better experience for reviewing a set of changes. Initially. But what if I told you there was a time when submitting email-based patches was the standard for version control? The author explains well how you can bear with patches, but not why patches were chosen in the first place. What advantages do they have over PR? I see none, and I won't lose my precious time working-around an inferior process to Github's already subpar PR one.

xigoi 5mo ago
Patches allow people to contribute without having an account on the forge.
musicmatze 5mo ago
You did not explain why the patch based process is "inferior", neither did you explain why you'd have to "work around" the process!
- mudkipdev 5mo ago
  Learning git format-patch, send-email, configuring SMTP, setting up wrapping, mailing list etiquette, versioned patch sets...
dapperdrake 5mo ago
Here is what email patches are all about: https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne... I tried email patches with another person myself. The only reason GH won here, is because the git people made one fatal mistake: They forgot to include the tree hash and only show the commit hash in the email patch. But the commit hash is useless. When you email patch, then commits people want to treat as "the same" and talk about have different hashes. The commit times differ and there is not only the commit author, but also the committer. We stopped doing email patches, because commit hashes became useless for communicating with each other. GitHub made commit hashes "constant" in a way people care about. For our purposes, tree hashes would have been much better in practice. The git user interface is literally "git porcelain". It cuts you for no reason.

m4rc3lv 5mo ago

For all the reasons the OP mentions, I am using Coderberg for a while. This is already in European hands - no cloud-act. https://codeberg.org/ https://codeberg.org/