But off topic from this, what is with all the sourcehut links on HN lately? Where did this suddenly come out of? Looks like a lot of cool projects are starting to host their code here. Wondering how it got the traction.
But off topic from this, what is with all the sourcehut links on HN lately? Where did this suddenly come out of? Looks like a lot of cool projects are starting to host their code here. Wondering how it got the traction.
1. It's faster. Mr. Devault, Sourcehut's author, runs a benchmark site that demonstrates this: https://forgeperf.org/
2. The e-mail based workflow is (in my opinion) superior; I don't have to use some clunky web interface.
3. I can run it myself, on-premise, for free.
Yeah but my email client can't show me nice diffs and let me comment on line numbers like GitLab/Hub can... Plus I
I don't really understand SH's decision not to support PRs, which seem fundamental to most workflows.
I think PRs are far superior than spamming up my inbox and using esoteric git email commands
To be fair, I've never actually tried an email-based workflow, but in my mind it involves a lot of emails and reply-alls and just general clutter and an absence of syntax highlighting, pinpoint line commenting, side-by-side diff and all the other nice things the GitLab/Hub provide with PRs.
>let me comment on line numbers like GitLab/Hub can
These are also being added to the web UI:
https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10253
But at the end of the day, if this workflow is not for you, there are a half-dozen other platforms you could be using.
I've never actually used an email-based workflow, but I'm trying to understand why people might prefer it over PRs.
SourceHut gets a lot of love on this site and I feel like I am missing out. But every time I look into it, I feel like there is something I'm not quite grasping.
I like email because it's very efficient, both as a contributor and a maintainer. It can fire off a patch with a single command, and reviewing lots of patches is easy, too. It's also distributed and federated by its very nature, which makes it fault tolerant and keeps your data from being locked up in a centralized/proprietary database.
I've toyed with going over to mutt, looked at alpine, and mulled over trying notmuch, lumail or even plain nmh.
Ed: for the mail curious, as some of these can be tricky to search for:
I find that the following are better in an e-mail based workflow:
- Reviewing
Threaded e-mail discussions are the best for following and/or discussing pull requests. Commits or comments no longer relevant can be hidden/collapsed to allow you to focus on what you are interested or is left to review. This is still not possible fully in either Gitlab or Github.
- Multiple versions of a pull request
Only Gitlab has support for multiple versions of a merge request. In Github there is no history of what the previous versions of the code were (or at least you cannot not explicitly compare them as in Gitlab)
- Merging into multiple branches
Though not enabled directly by an e-mail based workflow, with Gitlab/Github there is no way to ask the same set of changes to be merged into different branches in the same MR, you have to open two, and then you might issues with tools that integrate with them as they might have done the assumption that one branch is not used in two different MRs. So, even though daggy fixes[2] are possible, the norm seems to be to cherry pick.
- Custom styling
This varies with the e-mail client, but still is way better than any web interface.
The site itself has actually had many links over the course of the past two years:
- 46 from sr.ht
https://news.ycombinator.com/from?site=sr.ht
- 22 from sourcehut.org
Ooh? What did I miss?
The open core model is also ethically-poor.
Can you speak more to this?
The reason why many companies insist on using "permissive" licenses is because they're having an "open core" business model, and want to be able to include the work of external contributors into their proprietary versions, without asking the contributors to sign any kind of agreement.
I know multiple people working on multiple projects who would have been entirely willing and able to pay for the enterprise feature-set, were it not proprietary. It's not even a good business model! Solely aimed at large companies, GitLab has no regard for individual users or foundations & groups producing free software. Some people make the argument that because they offer the proprietary patches to free software projects at cost of nothing more than freedom, they do have regard for them, but that's a ridiculous argument: BitBucket was gratis for free software too.
If Drew somehow has a complete change of personality and ethics, that's when it'll be "It's not GitHub, GitLab, or SourceHut." But as it is, he's basically the only trustworthy business-owner on this site.
He even reps a "competitor" that actually supports software freedom as well: Codeberg.