Have the Forgejo developers shown any interest in supporting self-hosted CI runners on Windows and macOS? Or is that specifically out of scope for them because those platforms are proprietary?

The proportion of software engineers who have the living knowledge base of how to use PRs seems far greater than those possessing the knowledge of how to effectively use git send-email. Maybe it’s true that git send-email is much less work once you know it (I don’t know, never tried, only project I know of that uses it is the Linux kernel) but any “less work” analysis will have to account for the work of training others how to use it, amortized over the number of patches they send. And for open source projects seeking contributors, removing friction to initial contributions is everything.

I really don’t think PRs are more work. I just git push myorigin, and it prints a URL. I click it and, if it’s a simple case, just click Create PR (if it’s a complicated case you have to write a cover letter, just like you do with email). It takes longer to figure out what email address to send to for git send-email than those two clicks.

The real benefit of forge PRs comes after the initial send. I can force push to update the PR instead of having to resend emails, as often as I want, without spamming people. Countless times I noticed a mistake after the fact and quickly fixed it without having to bother anyone.

All review comments on the PR are linked in one convenient place and with a rich UI where you can expand code context without having to cross-reference a code editor manually. It’s almost impossible to review complex email patches without manually digging up context (and visualizing how the patch applies mentally, unless you manually apply it for real so you can use Git tooling!). I find that this encourages “lazy” email reviews that only consider the immediate code context because it’s too much work to pull up more, which often waste everyone’s time because the comments turn out to be invalid when considered with more code context. Meanwhile, a forge PR can be reviewed entirely in the forge, pulling up as much code context as you need on demand with a couple clicks. Comments are tied to the code context, such that you can see all comments from different people on one piece of the code together, instead of having to walk through separate email subthreads. Other PRs can be linked directly and commit IDs are clickable. Reviewers can suggest code changes that can be applied directly with one click.

Review and commenting occurs in parallel in one place, without having to break the conversation into discrete “versions” that are re-sent as unique PRs (and often end up with duplicated discussions as new people join who missed the context). That means I can be working on discussing changes A and B while I’ve already fixed C as C’ and someone is already reviewing C’, and D is already considered good and need not be re-sent to anyone if nobody has any comments on it. The UI automatically hides obsolete comments after that particular part of the code is updated (but you can still click to read them). There is an explicit concept of “resolved” conversations so you can keep track of every review change without having to do it manually in a text file or something (or worse, in your head, and then forget a few days later if you have to set the PR aside for a bit).

It’s easy to enumerate at a glance open PRs for a project, and there is a consistent notion of “closed/merged”, unlike email where there’s no programmatic way of doing that that doesn’t involve parsing human language with heuristics. And anyone joining in from elsewhere can just do it, without worrying about being subscribed to the ML or CCed in advance, or else they don’t have context in their inbox and have to cross-reference an ML archive or manually import messages.

And actually merging the PR is way easier too, just one button click for a whole series of commits vs. using something like b4 (which isn’t even part of Git itself) to download the mbox and apply it, or doing it manually via bespoke email client workflows message by message (and then if your email client doesn’t preserve whitespace properly, you’re in trouble). Plus a PR is explicit about the base commit, while bare patches aren’t, and then you have to either guess, ask, or ask for a rebase when they don’t apply (and Git can’t do useful automatic conflict resolution without a base commit, git am just gives up, unlike a rebase where you get conflict markers etc.).

And then there’s the manual email editing, and the endless nested quotes. That’s just a poor workaround for lack of rich, fine-grained threading and grouping with context! It creates visual clutter and slows everything down, because if I’m reading an email thread in sequence now I have to skip over all the quotes which I just read, and if I’m looking at a leaf message far down it was probably trimmed too much and I’ll have to look at the parents for context anyway. Clearly if you have a data structure which is a set of messages and replies to specific code context points, grouped by author/review, the efficient way to manage it is like that, not flattening it out to emails with duplicate context to make it fit a medium that cannot efficiently represent that data structure. Consider that a review implies commenting on multiple pieces of code, and while there is value to grouping them together, the comments usually stand alone. But nobody does email review like that, one comment per email. They get grouped together in one reply, and then replies to that splinter off, but the email metadata does not tell you which part of the email, which review comment, the reply is a reply to. And on the other hand, when the review is of multiple commits which are related, email has no way of grouping those together, because you can only reply to individual patches. I can fit a dozen comments and replies in one screen in a forge including the original code, while with email I can only fit one message, which might or might not have arbitrary context which may or may not be what I need depending on what the authors did while trimming quotes. And I can scroll up and down through the discussion seamlessly, while with email I have to jump from message to message (or at best get a GMail type view which is just a heuristic and may not get the threading/context right). Email is just not, at all, the right data structure to do complex code reviews with.

There’s endless other reason to use a forge depending on what you’re doing. For example, if your project involves artwork at all, forges can display and even diff images for you, while email clients just see a huge blob of base64 (because email flows also can’t integrate with attachments, which are actually the native mechanism email has for sending files). And that’s if your change even made it to the inbox and wasn’t dropped for being too large. Some projects have multi-megabyte resources and that simply can’t work with email, while Git handles it fine, especially if it’s an efficiently delta-able binary format (or there’s git LFS, which might kind of work with email if you send the changes to the LFS blob store and only email the identifiers, but I don’t know if anyone does that and why would you do that instead of using a forge with LFS integration?). Same with better integration with CI and code quality bots (which can suggest changes or fixes, and again those can be applied without the author having to re-send the entire PR, including going through several attempts at fixing a CI problem without spamming every human in the conversation).

What may be interesting is a bridge that converts pull requests from forgefed to email, so I don’t have to ever interact with the hosting website.

There are already several solutions along these lines. You can provide email interfaces for a forge flow, because it’s easy to go from rich structured content to plain text, and degrade gracefully when replies can’t be parsed back into rich content. The converse is nearly impossible.

Honestly, my intuition is that PRs provide at least a several-fold improvement in overhead over email flow. And for small changes overhead dominates the overall time spent on the whole change. The PR flow is also much friendlier to newcomers (just ask people).

Sure, with a forge you have to create an account upfront, but that is amortized among projects using the same forge or compatible login providers (quite common these days). And quite frankly, I waste more time dealing with the overhead of a single complex email code submission and review than it takes to create a forge account from scratch, with manual email/password login (if it’s OAuth then it’s just two clicks and it beats even simple email code review overhead).

Source: I regularly contribute to both large forge flow projects (Mesa) and the only large notable email flow project (Linux) and I very, very much prefer the forge flow. Even for simple changes like this one which had no review comments and didn’t need any of the post-send PR flow features I just mentioned, the email flow gives me significantly more anxiety and mental overhead, and that’s using b4 prep/b4 send which is already a huge improvement over git send-email.

IMHO a major failing of the email based workflow is that it doesn’t preserve enough commit metadata. Including the parent commit ID would help figuring out conflicts as well as avoiding missing dependencies. If the exact commit could be transferred via email it would also help future merges and updates as Git would understand that the commit that you sent as a patch is the same as the one applied by the maintainer. Right now that information is lost and when merging upstream back into your branch it can become a huge pain to resolve all of these false conflicts.

I just do git push origin HEAD:refs/for/main -o topic="branch-name" and let the magic of the AGit workflow do its thing (most recent example here). I do need an account on the forge, but if I plan to contribute to things hosted there, that’s a very small price to pay.

Other than that: I just clone the upstream repo, do my thing, and git push away. I get reviews in email, and can push my updates the same way, with a simple git push. It’s bliss, I very, very rarely have to interact with the hosting website. And even in the rare cases I do: it has an API, so I can do all my interactions through Emacs, after the initial registration.

Merging PRs is similarly doable without interacting with the site, and doesn’t even require anything but git itself.

Forgejo + AGit is <3.

They’ve made PRs super easy, honestly. When you push to a fork the server sends back a URL to create a PR and you just fill in the title and description like you would write in an email. If there’s only one commit, those are filled in for you. That’s less work than mailing around patches for me at least.

It’s not that hard to write tooling that makes opening a PR as easy as git send-mail.

The fundamental issue is that git send-mail works with email addresses, whereas PRs work with accounts on a git forge. Email addresses are in some sense more decentralized internet IDs than accounts on a git forge are; but both have serious issues.

Good comparison for this would be mastodon replies. In theory anyone could spin up an instance and spam you. In practice your instance moderators do a good job on spam detection and defederating malicious instances, so this isn’t a problem

None. Woodpecker seemed to work well. I just did not enjoy having a separate system with webhooks and much lower visibility. Integrated actions feel better to me. I use it for personal stuff, so I don’t exactly fret over alpha quality.

OTOH, our client is migrating to Forgejo including actions soon, so I guess my tinkering will pay for itself when I inevitably end up helping out.