"SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such."
https://news.ycombinator.com/item?id=23038520
(And therefore, perhaps, ill-advised to recommend it as such)
If anyone is skeptical about the email workflow, here's a write-up from another skeptic:
Where did this quote come from? You just made it up?
You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
No, it doesn't, and it's dishonest to try to make that move—just as it is dishonest to manufacture quotes (that are, in this case, designed to provide the opportunity for that attempt).
"Github but just without the gamification elements" does not appear anywhere outside of your own comments and is, in fact, much stronger than what was claimed in the original comment you responded to; the person to whom you responded and to whom you were being needlessly confrontational pointed to SourceHut as an option for people who dislike gamification and are looking for a provider that is just "a place to host and build code". There was no claim about the suitability of SourceHut for anyone who doesn't meet that description, let alone anyone who requires/seeks/prefers(/whatever) "Github, but without gamification elements".
Please stop manufacturing quotes, and please stop defending their use by pleading that "[t]he quotation paraphrases". That word sequence alone is a dense contradiction. Making up false quotes is especially troublesome when they are freely mixed into discussions where a person has otherwise already previously made use of genuine quotes (such as the way you did when quoting the creator's remarks that "SourceHut is not GitHub/GitLab/Gitea[...]"). To do so is pernicious, and the entire practice is against HN's rules.
I still think you're reading a lot into this thread that is not there, and ratcheting this up to the level of accusations of dishonesty is a pretty interesting/illuminating choice. However, I don't actually have a dog in the fight; consider all points ceded.
> I still think you're reading a lot into this thread that is not there
To reiterate the background for this discussion: a participant in this thread went a step further than what you're saying here and literally* wrote things in that weren't really there.
* literally literally, not the other kind
How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
A pull request, literally, need only be moving code from one repo to another.
The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means.
That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics.
E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them.
Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
Isn't that what discussion board is for? I agree that this particular topic is not life-and-death important, but still worth discussing, IMHO. If you think otherwise, just walk away, you do not owe anybody anything.
It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling.
(Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things.
Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.