Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement
And using it for a project that accepts this workflow is such a joy, no need to figure out weird merge request that make me re-enter all the information I had in my git commits already.
If it's only a few patches, say three, I can do a simple `git send-email --to mailing@list.example.com -3`, maybe throw in `--cover-letter` for some meta info if the changes are even big enough to require that, and be done.
Certainly to each their own workflow, and once can get accustomed to a lot of needless tasks and workflows, but how one can look at the bloated interfaces that try hard to add vendor-lock-in and say "this is so much simpler and easier to grasp" can IMO only mean they never tried this way in good faith. In the end sending a mail is trivial, and code changes are text (most of the time), it can hardly be beat in simplicity.
Anecdotally, most of our new hires from the last years had no experience with the email workflow, and a few weeks in most of them find it way better, while the rest finds it at least as good as the alternatives (and here they mean gitea or sourcehut, not the monsters that GitHub/Lab are).
You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
You mean cloning a repo and then simply pushing upstream?
I can’t fathom how anyone would think that is more complicated than e-mail push workflows.
It’s like someone telling you that IRC is “obviously” less complicated than setting up a Discord account.
Avoiding email based workflows and alerting is one of my top priority in every job I have had.
The linked article is literally a multi-step process of arcane terminal commands that differ by operating system. You may think it's easy, but it's definitionally not trivial.
srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case.
It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
I say that as someone who don’t like GitHub, but overall it’s far from the worst tool an employer may impose to its employees.
I funnily think that many of the people poo-pooing the email patch method here, would just as merrily join in on HN were it an email mailing list collection, haha! :)
It is often used in GitHub CI workflows.
Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
It's not off the table that we may give it a try again, because the advantages of having concrete pull requests (and issues and...) rather than patch series is pretty significant. But if you're familiar with doing email-based review, I think it's still a far superior; and you're definitely giving something up when you move away from it.
Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.
# do your code change
git commit
git send-email --to=<some mailing list> -1
# amend your change
git commit --amend
git send-email -v2 --to=<some mailing list> -1
Edit with minimal configuration:
cat ~/.gitconfig
[user]
email = your@mail.address
name = Your Name
[sendemail]
smtpuser = your@mail.address
smtpserver = smtp.whatever.com
smtpserverport = 587
smtpencryption = tlsYes, most contributors will prefer opening a PR on GitHub as apposed to mailinglists. But imagine instead that you are David Miller, and it's your job to consume the absolute fire hose of patches and messages related to Linux's networking subsystem. Would you rather wade through the hundreds of messages and patches coming in every day using either GitHub PRs and issues or email?
I would choose email for one simple reason: It's easier to script.
Even as a small-time contributor and observer to that space, I couldn't even imagine trying to keep up with everything going on if I couldn't bulk download, filter, tag etc. As a maintainer it would be excruciating.
A GitHub PR is way more steps than e-mailing a patch to a mailing list, and far less accessible. Have you never done the "sign the contributor license agreement and get the GitHub bot to approve it" polka? I've done it a dozen times now, it's painful and way more gatekeepery than just emailing a patch.
> but they also form a weirdly religious culture that fetishizes needlessly painful process and is incapable of improvement
Who hurt you?
It drives away the kind of people who have little patience for technology problems and little patience for learning new things.
I don't want those kind of people working on e.g. Git. Git needs people who have lots of patience for technology problems and lots of patience for learning new things.
like learning to use a GUI and a Web Interface?
There’s having patience and problem-solving ability, and there’s not seeing the value in jumping through the various hoops that comprise some ‘90s Internet fetishist’s playground.
This is all just code for “I’m old, set in my ways, and don’t appreciate the fact that the only reason I find my workflow easier is because I know it, not because it’s more intuitive than what people are doing these days”.
You've spawned a huge thread of people being incredibly self-righteous about the mind-boggling difficulty of sending email. It makes me think that it's actually a great filter to keep out people who prefer drama to clicking a few buttons that are different than the buttons they're used to clicking.
I understand that familiarity is a powerful driving force in human psychology, but really, it's not like it's that hard to learn a different flow. I mean, I've had to use Perforce, and while it's fun to complain, it really wasn't that hard. I didn't even have to get out of my chair.
Often that's a bonus if not the whole point to begin with. The higher the barrier to entry the less noise you need to filter through.
It only feels annoying to you because you're not used to it.
Copy the config, or better yet, version control it (or any of the other solutions to this problem).
^1
https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWF...
1. Email has clients with full offline support. Sometimes I work in locations where internet is bad to nonexistent and with github I am limited in what I can do.
2. Anyone can contribute to my repos without needing to sign up to my website. Git with email truly allows decentralization of “forges”. So in the same vain, I can contribute with the same client to any project on the web that accepts email patches and it’s the same workflow for all of them.
3. Since I have an email client for my email, I can set up my own custom workflow that is much faster. Github siloes you into a begrudgingly slow one. My email client integrates into my editor and gives me the same keyboard shortcuts I use to navigate my code.
4. Did I mention it removes centralization? Having github be the center for all repos makes it ripe for enshittification. Given Microsoft’s history for EEE, I don’t trust them one bit.
You could say the same of GitHub. Why do I need an account on your lil site just to get a patch accepted?
The git-send-email part isn't too bad. It's everything else I have a problem with:
- You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
- The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it.
- Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
- Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
- You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
- Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
- etc.
> - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/
If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getti...
And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way.
What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup.
But sure, there are some bad apples, especially most web mailer.
[0]: https://aerc-mail.org/ [1]: https://neomutt.org/
> - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one.
Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history.
> - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). IMO much higher quality of life than with the classic Git(La|Hu)b forges.
> - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started. If I use thunderbird I got my one directory for it, so I just mark all, save and execute `git am ~/t/aaa/*` in the repo. When I use aerc, then it's even simpler, it has built-in helpers for doing this easily.
Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh. Also, the interface often loads weirdly, as they manage their own history as a single page app which often gets in a state where button presses won't do much.
> - You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
git send-email uses base64 encoding for that, if the mail user agent of your recipient cannot handle that it's like their broswer cannot handle HTTP/1.1, switch that stuff immediately.
> - Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
Yeah, sadly sometimes needed for anti-spam measurements, here I agree fully that this isn't ideal, but FWIW, for Git(Hu|La)b I also need to create a account and fork, so it's not exactly zero work there too, but yeah, due to SSO and gaining access to many projects, vs. just one for a subscription that is not really comparable..
Maybe I'm missing something, but those seem like they are for searching mailing lists. I'm not sure how they solve the problem of, getting notified for threads I care about, but not for all of the other ones I don't.
> setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution.
Ok, so suppose that there is a patch submitted to fix a bug I care about. I don't want to reply, because I don't have any new information to add, but I want to know once the patch is merged. Yes, it is possible to subscribe to the mailing list and create an email filter, assuming that I know enough about SMTP headers, and i am already familiar with and use a powerful mail client, and only use a single client that I have those filters on. Or have a mail service with very powerful filtering functionality (unlikely). But I wouldn't exactly call it easy.
> List have a dedicated List-Id header, so one can easily filter them in a targeted way.
That's useful for putting all emails from a list in a folder, but doesn't help if you are only interested in a small subset of the emails for any given list.
> because the message medium is decentralized mail vs. a centralized HTTP API.
well, my biggest problem is that the granularity of subscription is far too coarse. It doens't really have to do with being centralized or not.
> there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup
I've tried using aerc and neomutt. I don't doubt that once you have them set up and have learned how to use them, they work well for this flow, but the learning curve is pretty steep. And they don't work as well for some of my non-development email.
> But sure, there are some bad apples, especially most web mailer.
In other words, the most popular email clients.
> please do NOT send new patch revision to the same thread, that just crowds review and adds nothing
So you just lose all the context of the previous review? And you review the whole thing from scratch? As a reviewer my preferred workflow for changes to a patchset is to receive incremental commits that build on the previous changes, then squash them before merging.
> I have reviewed lots of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer).
How do you handle commenting on large patches that change many files? I imagine in such cases you would `git am` the changes and view the diff using your git diff tool of choice, file by file. But then if you find something you need to comment on, you would have to go back to the email client, and search through the large amount of text to find the appropriate line to comment on. That seems rather tedious and disruptive to me.
> Here I can manage simple conflicts easily (e.g., using three-way-merge) on GitHub conflicts are a bigger PITA and need lots of manual intervention from me or waiting on the submitter, meh
FWIW when I deal with conflicts in github, I don't use the UI. I pull the branch of the PR, merge or rebase, resolve the conflicts, and then if the submitter allows, push the changes back up to their branch, or make my own branch. Then I wait for CI to finish before merging the changes post-conflict-resolution.
To be fair, I am somewhat biased, since I have a lot more experience with the Github flow than mailing list flows.
But I would also like to learn how the mailing list flow works in practice, in part so that I can contribute to projects that use it. It seems like there must be tooling and practices that I am ignorant of, but websites like the OP usually don't go any deeper than explaining how to use git send-email and telling you to use a better MUA.
Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!
You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.
GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the contribution side is so much nicer now.
(Bias/context: former GitHub employee, former KDE committer, current Homebrew project leader)
And then there’s a philosophical discussion if burning newbie’s time or discouraging them is worth making the old guard’s time more productive- including discouraging interactions entirely.
(This is why for certain projects you can be entirely useful even if you can’t code; just as an intermediary)
Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I realize that is probably not what you meant though. Besides, when email patching first began, the tooling was in its infancy.
However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better. I never actually use GitHub for merging, even when working on projects hosted in GitHub.
I’ve never managed to understand how to all those things, always switching between github web UI, github tools, command-line github. Everything was a mess.
Then I left github for sourcehut and managed to read a book about git.
It is still hard but now, everything makes so much sense. When I have a problem, instead of clicking everywhere and blindly copy/pasting results from stackoverflow, I actually think about my problem and what result I want to have.
Yes, the upfront effort is harder. It is like learning Vim or Emacs. It’s hard for the first few days/weeks then you get a lifetime of incredible benefits.
(Bias/context: I’m the author of https://ploum.net/2023-02-22-leaving-github.html )
Your skepticism is understandable! GH seeks to bring this collab to all, but back then the skill required to even contribute was a barrier. But in a way that barrier was acceptable and useful.
The people doing it were skilled. The basic level of skill required to even contribute was a lot. I think there’s something to that.
As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t. But yep, you got me; I did not contribute! I was an observer, with a genuine admiration for the simplicity and effectiveness of that method of contribution. How sending something as commonplace as an email can have profound implications when it carries a valuable contrib!
Indeed GH has some joy. Yet while convenient, modern tools might lack the intimacy and individualism of the older, more decentralized methods, which can avoid the immediate public scrutiny that GH may entail.
I suppose you can consider my words an ode to the old ways, and an invitation to consider whether some elements of the past should be reintroduced in today's collaborative environs. This might sound whimsical (and perhaps not entirely accurate), but perhaps the "email method" was even more eco-friendly!
It's not so much I think those things you list are a pain, just the overall "structure of collaboration and social organizing algorithms" (please excuse me; I'm finding this hard to articulate!).
If don't get the vibe of my comment, I totally understand! It's intended to resonate with those who witnessed the evolution of dev practices and share my nostalgia for the early internet of the 90s.
My memories of watching patches flying over those email lists are forever tied up with that whole early internet nostalgia. I loved that stuff. I read zines, and printed off RFCs so I could smuggle them to school and read them, just to “stay in touch” with online, even when we couldn’t connect. :)
Wait, are people doing this via the GitHub web UI these days? That sounds like a nightmare.
Very poetic, but also not much different to the current state. Just clicking to open a PR instead of sending an email attachment.
I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world.
I don’t find it very user friendly (well, at all), but if you want a git forge that does that, you can use it.
(Git was introduced in 2005, while Linux was first released in 1991; fourteen years separate them.)
Why not have all the content on one page?
Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?
git send-email is made for this, and handles all edge cases correctly, but depending on your MUA and/or it's config, it can work pasting patch diffs in there just fine – the point is that, especially for newcomers, and for a few edge cases, it may hard to do correctly and so using the tool made for the job avoids friction for all sites.
ps. ZIP wouldn't be required, just use base64 encoding, that's basically what git send-email does, depending on the encoding, line length, ... of a commit.
Re sending patches in email clients without using send-email, some clients (famously Outlook) try to be "helpful" and for example remove blank lines (double or single, don't remember) for example and will corrupt the patch in the process.
In any case, even the possibility of such an outcome is not pleasant.
Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.
And that having been said, I really GitHub/GitLab/etc. could move on from the pull request model and into a more change-oriented model like Gerrit or Phabricator. These are clearly better models in my opinion, and for most uses it's not even dramatically different.
git send-email --dry-run <commitish>
git format-patch -o<tempdir> <committish>
git format-patch --stdout <committish> > foo.mbox
People generally are helpful if it's your first time contributing, so if someone isn't right, I'm sure someone will help you get it right.
Can somebody elaborate?
>Be advised that Protonmail is generally known to be a pretty bad email host. [...] Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.
Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up).
It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.
Microsoft Windows but last, due to the W I guess but macOS has no Apple in it.
Windows deserves being at the bottom
How do you get to that conclusion?