I claimed in a thread today, that projects using GitHub as a mirror, but refusing to process pull requests were being unnecessarily hostile to newcomers. This could be automated.

I decided to check my claim. Hilarity.

Turns out if you append the six characters ".patch" to the URL of the pull request, GitHub serves up a plain-text patch formatted as an mbox format file.

The man-page for `git send-email` specifies that as it's first preferred input format...

So, yeah: mastodon.xyz/@HerraBRE/1015229

ยท Web ยท 6 ยท 15 ยท 23

@HerraBRE Well that's cool. I mean so as long as GitHub maintains that feature, but definitely cool for now.

@cstanhope Yeah, this could totally disappear tomorrow. Such is the nature of SaaS.

But for now, it's very low hanging fruit for building bridges.

@HerraBRE to me one of the best perks of the mailing-list-centric flow is precisely *because* it makes it so much easier to accept patches from a variety of sources. let casual contributors send patches from GitHub, core contributors can email the mailing list for discussion, others can link to a small .patch in an IRC channel; it all ends up in the same place in the end.

@kirschwipfel Correct. There are many ways to skin this cat. People just need to decide it's worth doing.

@HerraBRE that's handy. However is there any way to convince GitHub's infrastructure to email this out? The main problem we have with this sort of thing is you need and end-point for a web-hook which means having a server somewhere and someone to configure and maintain it.

@stsquad I don't know!

I agree that would be handy, I suspect GH don't do it for the usual corporate SaaS silo reasons, but I'm just wildly guessing.

My comment here was in the context of projects that have already written bots that interact with GitHub and auto-close the PRs.

@HerraBRE ahh ok. The #qemu project has a mirror on github but so far all we've managed is a comment in the project description and the occasional manual comment by one of the admins when someone submits them.

@stsquad If someone reads the email notifications and helps out folks that get confused, that can be enough. All depends how it's done, right?

It's extra work, but being welcoming to new contributors always is.

@HerraBRE sure and we try our best. It's less of a problem on PRs (who at least tend to come from someone familiar with code) than it is with bug reports. If you just copy and paste a form response pointing to our bug reporting guidelines that can come across as snarky but crafting an individual response to everyone saying thanks but you missed some vital information can get quite wearing.

@HerraBRE I had on separate occasion posted that same vid today! Spooky.

@HerraBRE A point of using emails is code review. While I don't like this UI, I observed a maintainer on a project that preferred this way of collaborating and the mutt-based workflow. Mutt was the code review tool.

Pull requests on GitHub are often also noisy, with commits containing "useful" auto-generated titles like "Updated README.md" and no further info. Or email address in the .patch may be wrong "george@Georges-MacBook-Pro.local".

Were I running a project based around code reviews in mutt over a mailing list, I might not want to manually import PRs, or assume that I should just blast the commit onto the mail address for review.

GitHub can be a nice read-only mirror; some people don't care about its so-called "community" aspects.

Not advocating for or against using Git web UIs (proprietary or not), just offering a different PoV here. I wouldn't easily call it hostility.

As an example: There are some projects where I have admin privileges and where an external issue tracker is in 10yr+ use, so we disabled the GitHub one; no way to do it with PRs, however. So the existing community is forced to look at a tool it has no interest in (and, because of copyright assignment policy towards a free software organisation, maybe even cannot accept). No hostility to user intended; merely result of an existing way the community operated since before Subversion transition and way before Git transition.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!