Hacker News Reader

Comment by NoGravitas | Hacker News Reader

I publish my public FOSS work on a self-hosted Gitea. I don't allow account creation, and people can send me pull requests by email. That said, I think one thing (other than interface and brand loyalty) that keeps FOSS projects on GitHub is network effects. You can reasonably expect to search it and find the projects you're looking for, and your account lets you use the issue tracker and pull requests on other projects. I think forges are unnecessary in general, but to wean people off of GitHub, FOSS forges like Gitea need to federate, so that you can search the whole space of public federated forges, and an account on one lets you open issues and pull requests on another.

They seem to be making slow but steady progress on this at Gitea, maybe at other FOSS forges, too.

View on HN

Gitea (and a few others) are working on federation for pull requests, which would allow someone to fork your project to their own server, and send a pull request offering you to merge from their server into yours.

It also builds on top of ActivityPub which is supposed to allow federation with the greater ActivityPub ecosystem ("fediverse"). I guess this would allow people to like or comment your issue or pull request from Mastodon and those other platforms.

I am not that excited about that last part, but federating pull requests sounds like a killer feature and a necessary step for a chance to topple GitHub. If hosting my own forge means I have to either get patches over email or let people register so they can create their own fork here, it's a non-starter for many.

edit: here is Gitea's issue: https://github.com/go-gitea/gitea/issues/18240

Hot damn, that sounds awesome. Easy PRs would be a huge step to getting me off GitHub.

Why is gitea hosted on GitHub? That seems ironic.

Gitea and Gogs weren't originally meant to be replacements for Github. They were meant for self-hosted internal repositories. That's why they are still on Github, even though hosts like Codeberg use them for public hosting these days.

It's getting close to be hosted by gitea: https://github.com/go-gitea/gitea/issues/1029

> I am not that excited about that last part, but federating pull requests sounds like a killer feature

Git already has a pull request feature [1] that's as federated as it can get. The 'request-pull' command can be used to request pull on upstream repositories hosted anywhere (or not at all). The only requirement is that the downstream clone must be online. I know that HN isn't particularly found of email-based workflows for git. But requesting a pull is as simple as copying the output and mailing it (or via any text messaging service) to the maintainer. And doing a pull as a maintainer is actually easier than doing local PR merges using Github.

[1] https://git-scm.com/docs/git-request-pull

> I know that HN isn't particularly found of email-based workflows for git.

I would think it's not just HN. Do you think people are using github PR feature because they just don't know about the email-based workflow available, but would prefer it if they did? Most people don't want an email-based workflow here.

> But requesting a pull is as simple as copying the output and mailing it (or via any text messaging service) to the maintainer.

I love email based workflows as much as anyone but for many people this is not "simple". For one, you need to be able to send plain text email or at least not have your client mangle it too much.

I can see this being difficult for random people, but I can't imagine it being a hard ask for developers.

A pull request on a Git hosting platform is much more though. It allows commenting, tracking versions of the branch, and showing the diff. Even if the pull request is denied, those comments and the diff will stay available for all to see.

You can replicate that with email with a patch-based workflow, if you have a mailing-list server with public archives. That is not that much less software, and you have to deal with email deliverability etc.

Simply sending someone a git-request-pull doesn't carry anything for posterity. It contains a link to some place that hopefully contains the changes at one point (if you typed it right, git does no validation), but probably won't contain them for long.

IMO it kinda speaks loudly that Gitea's development happens on github!

There's a reason that's the case, and it's likely one of the reasons I should just use github as well; despite being morally opposed to what they're doing WRT copilot.

> IMO it kinda speaks loudly that Gitea's development happens on github!

There's a bug for that: https://github.com/go-gitea/gitea/issues/1029

That's because when Gitea was early in development, it would have been not usable enough to develop itself (the Gitea people have a post somewhere explaining about it; how too-early dogfooding can actually make things worse as you try to implement 'urgent' features in a rushed manner rather than taking the time to do it right).

Sibling has already provided the tracking issue for getting off it; as far as I remember it's close now :-)

For early development that makes sense. But if Gitea is not ready to self-host now then it is also not ready to host most other projects so that doesn't really invalidate the criticism. However from the sibling comments it seems that the move to self-hosting is in progress.

It looks like the only feature blocking their move to self-host is importing data (issues and PRs) exported from GitHub. Which is to say, it's perfectly ready for hosting new projects.

I love email & personally prefer it for communication, but there is an entire cohort of developers headed your way who rarely us it outside of "job-realated requirements".

A possible middle ground here is to allow GitHub OAuth2 logins to your Gitea instance - then at least GitHub users can join in your project without too much friction.

Yes! Federation is so important. Federation for issues or issue triage on something other than Gitea would probably be important.

Better start self hosting gitea right now. And you can do it for free. I think the best option is oracle cloud, or does someone know how well it works on fly.io? https://paul.totterman.name/posts/free-clouds/

> people can send me pull requests by email.

Great, you already lost half of them.

Generally the ones I don't mind losing. If anyone can't figure out how to send a git pull request or patchset by email, I'm happy for them to email me with questions on how to, which I will answer as best I can.

I can figure out how to send you a patch set via email (see my Linux kernel contributions), but if I can avoid doing that, sure as heck I will. Your project must be really important to me, or I have to get paid.

As for the reason, it's simple: the process of submitting patches sucks. I wrote about it: https://dcz_self.gitlab.io/posts/git-botch-email

Based on your first example of running git send-email without providing it any patch files or revision list, you appear to be making the assumption that someone doesn't bother reading the documentation before using the tool.

This would be like someone trying out make the first time and not realizing why it isn't working becaue they didn't realize they need literal tab characters in the make file for the rules to work. But if they don't read the documentation, there's no way they would know that.

The real problem is people trying to figure out how tools work by experimentation as opposed to reading documentation. If someone reads the documentation of git send-email and the project's contrib document contains the preferred settings for that utility, then submitting patches should not be an issue.

That's a valid observation of one of the reasons I won't use git-send-email.

I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs.

Keep reading, there's more criticism on other aspects of the tool.

After reading through the rest of the post, I do see your point. When I last tried it, I thought that most of the email formatting should be done with git format-patch and then git send-email should be used to actually send the email without having to answer any questions.

That would address one of your concerns about saving the email on disk and also ensuring that the headers have the correct contents.

If the project's contrib document contained information about what settings to use for format-patch and send-email, then the process would be much more seamless. I haven't looked at the kernel (or subsystems) documentation on that. The git project itself doesn't seem to contain that information though.

Regarding your other point about using your email client to handle sending the emails, git does have a utility called imap-send that would allow you to upload the patches to an IMAP folder, which, I believe, would allow you to then send the messages using your MUA of choice instead of git send-email.

Seconded. It can be a lot of effort to just set up a client which won’t mangle patchset emails. Maybe Mutt etc. users get that for free, though.

You could mail patches as plain text attachments, if there are concerns about the clients mangling them. You could also try some easier plain-text clients instead of mutt. Claws mail is a simple GUI based one.

[1] https://www.claws-mail.org/

But projects like Git do inline patches. I wouldn’t have the guts to break a convention like that when trying to submit something to the mailing list.

Honestly, if you can't be arsed to format an email then why should you expect anyone to spend the effort to review your patches and maintain your additions going forward.

Drew DeVault created this[1] to help people start using git send-email. I'm not sure if it works for the purpose of contributing to your project, but it may save you from having to explain the same thing repeatedly :)

[1] https://git-send-email.io/

I want to add the guide to submitting patches for the Linux kernel [1]. It contains a bit more finer points, in addition to what's on the site you linked.

[1] https://www.kernel.org/doc/html/latest/process/submitting-pa...

Honestly it's not that bad. If you don't insist on getting correctly-formatted email for git-am, most people manage fine. They'll send you the output of git-diff, a git-bundle, or attach the files they changed.

Any of these would be acceptable to me.

Actually, I don't understand why should I cater to all needs of all developers. I'm opening the code, accepting PRs, and these are my terms. You can agree or disagree.

If you really want to contribute, but don't want and e-mail based flow, send me a mail, and we can discuss.

Reply on news.ycombinator.com