Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A beginner's guide to Sourcehut (2025)

btxx.org

Post reply on HN
Print view View original

11–18 of 18 posts

Re: A beginner's guide to Sourcehut (2025)

#11

Post by steeleduncan »

KolmogorovComp wrote: post #6

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 firs…

I think there is a strong argument that Gerrit is the current evolution of the patches workflow, many prefer it, and there are a lot of good blog posts explaining why.

I don't know what the justification for emailing patches around is though, that seems needlessly painful in the face of alternatives

Re: A beginner's guide to Sourcehut (2025)

#12

Post by IshKebab »

dapperdrake wrote: post #10
KolmogorovComp wrote: post #6

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 firs…

Here is what email patches are all about: 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 s…

That's not the only problem with git send-email by a long way. Even the setup process is extremely painful.

Re: A beginner's guide to Sourcehut (2025)

#13

Post by xbar »

topham wrote: post #2

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).

If your only concern is copilot, this is accurate.

For Micrsoft-competitive, closed source projects, SourceHub is a much better choice than GitHub.

Re: A beginner's guide to Sourcehut (2025)

#14

Post by negura »

dijit wrote: post #3
topham wrote: post #2

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).

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.

codeberg serves a poisoned AI page when the detection is triggered

Re: A beginner's guide to Sourcehut (2025)

#15

Post by mcc1ane »

KolmogorovComp wrote: post #6

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 firs…

I believe I've read something by Drew DeVault about it, but I can't find it.

The closest I found is this - https://drewdevault.com/blog/Code-review-with-aerc/ - although it has broken links.

Re: A beginner's guide to Sourcehut (2025)

#16

Post by xigoi »

KolmogorovComp wrote: post #6

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 firs…

Patches allow people to contribute without having an account on the forge.

Re: A beginner's guide to Sourcehut (2025)

#17

Post by xigoi »

aniviacat wrote: post #4

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?

Having to create an account adds friction and requires you to agree to shady “terms and conditions”.

Re: A beginner's guide to Sourcehut (2025)

#18

Post by mudkipdev »

musicmatze wrote: post #7
KolmogorovComp wrote: post #6

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 firs…

You did not explain why the patch based process is "inferior", neither did you explain why you'd have to "work around" the process!

Learning git format-patch, send-email, configuring SMTP, setting up wrapping, mailing list etiquette, versioned patch sets...
Post reply on HN