Email and Git = <3
git-send-email.ioI appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd.
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
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists.
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).
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" <snipped>.
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.
In what cases is it tricky? I find that most projects use some version of mailman (like QEMU - https://lists.nongnu.org/mailman/listinfo/qemu-trivial) and then it's just a question of filling out the form and hitting "Subscribe". I cannot remember project I wanted to contribute to, I had to use git+email and it was difficult to subscribe to the mailing list they want me to use.
How is that harder than signing up to Github?
I only have to sign up to Github once, not once per project.
That’s because Microsoft GitHub is a proprietary monolith. Compare that to the open core & self-hosting of GitLab the more FOSS-positive space where each server (without federation) requires a new sign up, confirmation emails (meaning you already had to go thru email), CAPTCHAs, setting up new keys, etc. That said, you will need to get your email filters in place or you can get a lot of new, unwanted mail (assuming you are required to sign up which often isn’t the case).
Personally, it's not. I'm using GitHub and I also sometimes send patches in emails.
I'm asking specifically what part of subscribing to mailing lists is the tricky part, as that's what parent mentioned. I'm not saying it's easier/harder than GitHub's workflow.
I think you meant “how is signing up for GitHub harder than that?”
Oops yes.
And then every so often mailman hits you up with "I'm receiving all these bounces from your email server!" because all the various garbage anti-spam techniques were not quite thought out with mailing lists in mind or people have lots of misconfigured servers and servers with different acceptance criteria, and it's all a big mess.
Configuring git send-email is only half the battle, anyway - chances are you want to participate in the discussion of your patch, so better figure out how to make sure your email client will not send the forbidden HTML email.
That's a battle??
This sounds like hyperbolic brought on by dislike, not a real indicator of time cost/effort. You've already spent more time complaining, than the work done to do these things!
There is usually no need to subscribe.
This. You just To: the mailing-list and depending on the project CC: the maintainers.
No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.
That's how mailing lists should work.
Many mailing lists today reject posts from non-subscribers.
Of those that allow posts from non-subscribers, you will find that many are configured such that you will not get a reply, due to "reply-to munging". Your message will go to the list, but with a Reply-to: header designating that list, instead of (or in addition to) setting the more modern mailing-list-related headers.
Reply-to-all isn't a list policy; it's a behavior of the individuals. Some people don't reply to all. They think they are, but only the post author gets their reply. That is one of the motivations behind the Reply-to.
https://marc.merlins.org/netrants/reply-to-still-harmful.htm...
The CC part is highly conflicted. Most maintainers hate double emails, whilst some loudly insist to be CC'd, esp. the Linux kernel folks. So you need to read beforehand the preferred etiquette. And nevertheless, the tone on mailinglists is entirely different (and mostly extremely childish and unprofessional) than on ticket trackers.
> not the monsters that GitHub/Lab
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.
There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity.
People in this thread are talking past each other without realizing that they are expressing different preferences about where complexity belongs in a tool.
(For the record, I happen to be on the IRC / git mailing list side of the spectrum.)
“Obfuscated complexity” aka good UX that decreases friction and increases velocity.
Again, friction and velocity of what? It's a lot easier for me to write an IRC bot than a Discord bot. But other things are much harder to do with IRC. People are looking at different vectors.
your parens enclose the most unneeded addendum i have ever seen
That's surely hyperbole. You can just say "This is unnecessary" and it achieves the same purpose. Maximalist comments like this tend to amplify the tension in these sorts of discussions.
yes it is hyperbole
For most channels you don't need an IRC account. And there are web interfaces like https://web.libera.chat/.
I'm trying to subscribe to Discord. I'm currently stuck in a captcha loop.
100%.
Clicking a link to open a chatroom directly, with no account creation process, is infinitely simpler than account creation, potentially with several layers of verification (CAPTCHA, email, phone verification to join a server...).
You mean
- cloning the repo in github to your own fork
- cloning your fork locally
- pushing to your local fork after you've made your change
- opening a PR
Which is the expected flow for any project you're not already part of, ie all of them.
The email workflow:
- send an email
I can't fathom how you can say the email workflow is more complicated.
No thank you.
Avoiding email based workflows and alerting is one of my top priority in every job I have had.
> Configuring git send-email is trivial
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.
Multistep is fair, though for the record "multi" in this case means 2. One of those steps (the only thing that differs by OS) is installing git- I think you'd agree that gatekeeping by ability to install git is pretty reasonable for a project that uses git. Using git send-email doesn't require much more configuration than configuring ssh keys to push to GitHub. The fact is, most open source development workflows outside the safe confines of java on intellij will rely on the ability to use a few commands. We're better off making more great documentation like this to help new people adjust than deliberately clipping their wings.
'Arcane terminal commands'? These are standard basic terminal commands.
The thing that differs by OS is the installation of Git.
Is this installing git?
sudo -H cpan Net::SMTP::SSL IO::Socket::SSL
I have absolutely no desire to send all of my companies intellectual property to a mail server. It could be the best workflow in the world, but if one email address gets breached, you're leaking everything and that's really unacceptable.
Isn't this also the case for centralized git servers? Even moreover if you run a monorepo.
No clue, I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals.
> I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals.
Like a mail server?
I don't know, sending sensitive information over plain text doesn't scream security to me. So no, unlike a mail server.
It's 2023; mail servers have been using TLS for a very long time.
Yes, you can transmit messages via SMTP using TLS, but you don't need any special tools to read the email once it's reached its destination which is the point you seem to be missing. And before you scream PGP, almost nobody uses it.
But that's exactly the same as anything else; you move git commits that you store locally (either encrypted or not) over an connection that's encrypted in transit (whether SMTP/TLS, HTTP/TLS, or git/SSH) to a remote server that stores the repo/commits (either encrypted or not). None of this is different depending on whether the remote is a mail server or github (or whatever).
TLS secures your message till the endpoint which is a (plaintext) code repo. Why would you want a special tool to read plaintext code? Your argument makes no sense whatsoever.
I’m not sure what you’re getting at here but it sounds more like an irrational hatred of email than something genuinely technical to me.
So, like a centralized git server ?
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger.
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.)
Some of the largest and most important software is developed over email, e.g. Linux, QEMU, Firefox, etc... Don't make the mistake thinking that email doesn't scale. In fact, for most teams, the opposite is true.
This is like saying that pyramids were constructed without modern cranes and bulldozers so obviously it's the right way to build stuff today. It's clearly not true but there are many power-wielding individuals in these projects who prefer to browse the web with lynx or develop in emacs and will impose this on anyone that would like to participate.
This is wrong.
No one is forcing you to contribute to, or even use, software that uses an email-based workflow. I’d also put money on the fact that the majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow.
> No one is forcing you to contribute
This is exactly the problematic attitude. I'm an OpenJDK author but not linux kernel contributor for mainly this reason. There are many people like me.
> majority of contributors to Linux, an extremely successful free software project, prefer the email-based workflow
This reminds me the many absurd conversations I had from my time in Goldman Sachs, few years ago. People with 15+ year tenures claiming Slang is the best answer to any- and everything. They just didn't know any better and stubbornly stuck to tooling and mindset straight out of 1995.
Not to derail the conversation, but Slang is incredible. Its interface is old and archaic, sure, but it's the best and most expressive coding experience I've ever had. It took some getting used to (especially case-insensitive variables with spaces ?! and the UFOs) but I really enjoyed working in it. All of the other workflow tools, like Procmon, were icing on the cake.
The internal cloud was just getting up to speed when I left, and that was more modern and also a joy to use.
There's a lot to dislike about working there, but in my experience, the firmwide tooling was excellent.
All of the largest software is collaborated on over webapps, without exception.
Windows and Office and AWS and GCP dwarf these foss projects.
There is a reason that Google, Amazon, Microsoft, and Apple don’t use email to collaborate on software.
> when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger.
You cannot possibly claim that the other side needs to cite their sources and then throw numbers like that out without any backing.
I have no great love for GitHub, I avoid it for my own projects but their official cli client is pretty functional and there are just tons of other clients, graphical or not for GitHub, GitLab etc …
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.
What on earth is "fake-usability"? It's more usable, just admit it.
Fake-usability is when 97/100 software developers find something more usable, but it's fake because I've invested a lot of time doing it a different way and gotten used to it.
GUI is fake-usability now?
Fake Edit: Oh this is HN. Never mind then.
Isn't it weird that such people bother installing a windowing system at all? Just work off the login terminal bro, it's perfection.
This is well said and insightful! I will reflect on this kind of phenomena and suspect I will be able to see it in the world going forward. Awareness of this will be useful to avoid the pitfalls described here. Thank you for making this contribution! :)
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! :)
In case of GitHub you have this for example : https://cli.github.com/
It is often used in GitHub CI workflows.
Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review there.
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.
>Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.
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.
I like git patches...I can scan through them, write comments, and maybe strip out files that aren't necessary (if you have two isolated networks and are syncing code in between). I'm a fan of some of these ambitious git projects like GitLab but there's just something about syncing git through patches (like email).
Well yeah, replying in-line to the patch to make comments is definitely a requirement. :-)
You always reply with quotes; and you always reply inline, below the thing you're replying to. Quoted material is typically indicated by '>'.
So for one thing, you can easily trim your reply to just the bits of the patch that you think is important; that makes it easy for anyone reading; you don't have to skip over large parts of the thread.
Then you can also re-arrange what you're replying to, to make it make your reply make more sense.
Furthermore, suppose A replies to the patch and makes comments 1, 2, and 3 (inline in a single email). When person B replies to A's email, they typically also send a single email, perhaps with replies 1' and 3' (trimming out comment 2, which they don't care about). This means if you've read A's mail, you can just read B's mail, and all the "new" comments are collected in one place (with the thing they're replying to).
Contrast the above with gitlab, where A's replies 1, 2, and 3 are spread throughout the patch; and B's replies will also be spread out, meaning you have a kind of discoverability problem to see both 1' and 3'.
And suppose in the course of talking about something you realize this bug may actually be a security issue -- you can remove the list, cc' "security@", and pick up the discussion without having to do any copy & paste. Same goes if you want to make a private comment, or bring something to someone's attention; just reply, remove everyone else, and say "FYI".
I wish I had a really good recent example to show you, but a quick skim of today's threads isn't anything special. :-)
I mean, I was arguing with people online [1] on BBS's in the early 90's, and I was on Usenet back when that was the main social network; so this "reply and comment inline" way of having a discussion is pretty well ingrained for me. But there are people on my team in their early 30's who also took to the email workflow really quickly too.
Thanks for taking the time to respond. I'm surprised to find that there are people out there who think endlessly nested >'s are a good solution, but it's always nice to have one's world view expanded :)
For one thing, most GUI mail readers will automatically convert the `>` into nested block quotes.
For another, it's not common to see more than 2 levels of `>` (your text, the thing you're replying to, and the thing they're replying to); and yes, when it gets past 4 it begins to get really unreadable, so my gut feel is that it's extremely rare (although I wouldn't be certain without doing some sort of data mining).
As I said, the main advantage of using email is the flexibility you have in editing the response; part of learning how to use the review workflow effectively is learning how to present the context; which means trimming the replies to balance information and readability.
It really kills the fun when contributing to any FOSS project that fetishizes these tools and holds them up as some kind of proof of hacker cred. I've given up. The latency is too high and the tools are terrible.
“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.
Subscribe to our mailing list, where we are rude and dismissive if you accidentally dare make a line longer than 50 characters, (didn't you read our netiquette?) as some members like to read their emails on outdated devices without text reflow capable display software. Also don't dare to use non-ASCII Unicode characters, or we will be rude and will ignore your request. Just spell your name in American, because that is what real programmers do!
Even better is when people post issues on Reddit or whatever asking for help because that's the most low friction way for them to ask, and then a project contributor replies with "hey can you send this to the mailing list?" and so the person sends it in and is met with exactly fucking this. It's just such a great use of everyone's time.
You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".
Damn, this is ugly and confusing, I mean, look at the threads XD! I'm glad I must not use this shit.
Shh now. A basic interface that took 5 minutes to make in 1995 is good enough for all eternity. No need to change it.
I certainly love navigating a million times back and force to read what should be a single thread.
I also love all the "new" threads generated by mail gateways changing the subject to something the likes of "Re: [EXTERNAL SENDER!] Re: Topic"
This interface is awful. I wish GNU would make more of an effort to be easy to contribute to.
I usually know, when the interface is not too shiny, that the content might be good. It's the same with HN. And those interfaces are still very easy to understand and use.
That being said, there is certainly room for improvement.
There's something to this idea, I think. The less polished a tool is, the more I'm inclined to think it was built by the community for community use. There's so much talk about enshitification, and I'm struggling to recall when a tool with a less-than-polished interface had that problem.
The example that springs to mind is spamgourmet, which has a FAQ about why they don't redesign their site. I've used the service for about 20 years, and while there is a bit of a gatekeeping vibe to it, there is also a good reason: they have very few resources for support, and want to attract a certain crowd to minimize the support burden. It seems it's been working for a couple of decades, at least.
> Q. Couldn't you make the whole thing a lot easier to understand by redesigning your site and providing instructions in a more clear way?
> A. Probably. Frankly, we're trying to build a user base of people like you, who probably have some familiarity with the way email works and who are willing to read FAQ's. This is to keep our support burden to a minimum (this is a non-commercial service). So far, the approach has worked well -- just about all our users hit the ground running with no need for support, and it's our belief that those users who would require support generally don't sign up in the first place, perhaps because of the geeky presentation of the site. That's not to say we don't provide support where it's needed -- after skimming this FAQ, please don't hesitate to write if you have a question or believe there's a bug.
https://www.spamgourmet.com/index.pl?printpage=faq.html
I tend to actively seek out projects like this, since I don't mind the blow to usability, and very much appreciate that they provide the service and don't pepper me with annoucements about their new improvements or their changes to their pricing structure.
You don't have to subscribe to send a patch to a mailing list.
I have more than once subscribed just to report a bug or send a patch because the mailing list rejects emails from non-subscribers.
Edit: Btw, yes I have done the periodically-check-archive thing in the past, thank you. Hated it. Also missed a response once because I forgot to check and replier didn't CC. I realized like a month later.
It is unfortunate that there are poorly-managed projects with poorly-managed mailing lists (just like there are poorly-managed projects on Github), but sourcehut at least requires a properly-managed mailing list, and I think you should evaluate this workflow on that standard. Tell poorly-managed projects to move to sourcehut, if you want to fix this issue.
Even then, you’re free to opt into daily digests if you’re a subscriber. The message ID allows you to reply to individual messages and threads nonetheless.
Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.
Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.
I know more than one occasion where that has gotten an angry reply.
It's also not the default in many clients. It's tedious and error-prone.
Genuine question: why is this a problem? Every modern email provider allows you to set up filters that move all the mailing list emails into a seperate folder/tag, skip your Inbox, and set up auto-cleanup to delete emails older than X days so that the volume doesn't result in you exhausting your storage allocation. And if you find yourself never actually taking part in that software's discussion and it actually turns out to be completely irrelevant to you, then unsubscribe...
"Want to contribute ? Open yet another account" Nope
"Want to contribute ? Give Microsoft even more power" Nope
This is a biggest blocker.
That’s an interesting take actually. Would you be okay with a service that supports both email and PR based dev flows as long as the user can choose?
I'd be interested in something like this.
I'm not sure what is needlessly annoying and absurd.# 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> -1Edit 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 = tlsYou left out the entire configure SMTP step. Honestly I’m not even sure how to do that if your SMTP server requires 2FA and does not allow legacy app specific passwords.
There are instructions provided for Gmail and some others:
https://git-send-email.io/#step-2
A tool from Google is mentioned and linked to:
https://github.com/google/gmail-oauth2-tools/tree/master/go/...
That uses app specific passwords, and with Google Workspace, the administrator can completely turn off these “less secure apps”. Pretty sure Office 365 has the same.
Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for generating a new refresh token every few months. It’s a heck of a lot of stuff to maintain, but at least it works. If anyone’s interested I could provide links or upload the modified versions to fix o365 quirks.
Multiple enterprise customers use my software (https://emailengine.app) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, but as a software developer, I'm really happy about it. Helps with my sales effort :P
Oh that’s pretty cool, thanks for the link. I’ve used davmail as a proxy like this, just for the oauth support, but it doesn’t scale to large mailboxes or high traffic well at all. May forward this along for some of our internal services people.
You can also use this (locally-hosted) proxy of mine which transparently adds OAuth 2.0 support to any IMAP/POP/SMTP client: https://github.com/simonrob/email-oauth2-proxy.
There’s another method that doesn’t use app specific passwords but I’m not entirely sure how it DOES work - it opens a connection and then gives you a web address to go to in your browser to authenticate with 2fa. And then somehow it magically works until it decides it doesn’t like you anymore.
I never studied the protocol of Gmail/Exchange/etc. 2FA, but I suppose the SMTP auth token expires after a while, and the client somehow hasn't implemented token refresh? Anyway, glad to know there is a way (?) to get git-send-email working with stricter 2FA.
I've always assumed that the server side stores as much information about the client as it can, so not just "username/password" but source IP, client headers, etc and somehow uses that as a "session token".
The tool from Google that is linked to appears to use oauth2.
Every mail server/provider that provides 2FA that I used allows for configuring "tokens" (called a bit different everywhere) which are a high entropy random string, and some of them require TFA only for IMAP or POP, i.e., getting mail, not SMTP, i.e., sending mail.
If you use this proxy of mine then any IMAP (or POP/SMTP) client can be used with a “modern” email provider, regardless of whether it supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
They said they found it difficult to configure, not that they found it difficult to use afterwards.
If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig:
(only the ones starting with "smtp" are relevant for mail, the other ones are just there for convenience)cat .gitconfig # snip [sendemail] to = default@list.example.com annotate = yes suppresscc = self smtpencryption=tls smtpserver=imap.example.com smtpserverport=587 smtpuser=foo.bar@example.comAnd that has to be done once, iow., in essence it's as hard a setting up an email fat client like thunderbird.
FWIW, I haven't done that kind of setup for years because modern iOS/macOS does email server discovery, where you enter "bob@example.com" and then it does discovery and figures out the right imap.example.com:587 etc for you by looking at DNS.
Yes, such things are nice. The well-known URI [0] system is also sometimes used for this, at least there's one entry for Thunderbird under the "autoconfig/mail" subdirectory. Having some of those auto-config methods available for git send-mail could be nice, as it would lower the barrier a bit further, even if most devs are probably able to check their SMTP endpoint and port.
It's also possible to not be religious about it. Git is distributed. I have projects on srht and contributing does not mandate using the send-email workflow. "Push it somewhere and let me know where I can pull" always works too.
Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.
The largest open-source software projects in the world don't use it though, so that tells me there is something lacking.
Maybe so, but my interpretation is that there's personal opposition to change and improvement from people like Linus or TGLX or other greybeards. At least in the linux kernel world. The contribution by email is an antiquated approach and needs to go.
Now, knowing the HN crowd this comment will become grey in 3... 2... 1...
What is antiquated about sending patches via email? Have you ever used email to contribute to a project or review a patch?
Contributing patches via the Linux mailing lists is worse than Gerrit in every way.
It really isn't, it's basically `git send-email --to=linux-kernel@vger.kernel.org -1` – how's hard?
Oh, sorry, you actually need to figure out the maintainers, so you can send it directly to them too to get it reviewed faster, so yeah a call to `./scripts/get_maintainer.pl -f <files>` ok, now it got impossible for the modern dev – cannot expect those are able to actually understand basic systems.
Then reply to the review replies you get, if there's still anything to change, how would gerrit making that easier in any way?
What is worse about it?
They say that scientific discovery advanced one death at a time. I imagine this same theory applies to kernel development tooling.
I understand not changing for change sake. The kernel is at this time not "this gen" developer friendly.
Largest open-source software, perhaps Chromium or Android, uses Google's proprietary systems with Git.
It's easy to forget the maintainers' side of this.
Yes, 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.
Github has an api for this…
And once you've used that API to download and tag everything, what tools do you use to interactively view the results, run search queries, apply patches to local trees etc?
If your on-disk format is an Mbox or a Maildir, you can use tools like notmuch and its emacs integration to do it.
Now don't get me wrong; I love GitHub. I host all my projects there, and I prefer PRs+issues to mailinglists in almost all cases. But for massive projects like Linux, a mailinglist (and associated tooling) scales better, in my opinion.
Which eventually will change, and you have to update everything. Or the company disappears and you have to move somewhere else.
Email is just email. You write SMTP/IMAP clients today and they'll continue to work for a long time, probably longer than most platforms with APIs online today.
It’s easier for contributors too, you don’t need an account.
> workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors
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?
> not only drive away a significant number of potential contributors,
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.
> It drives away the kind of people who have little patience for technology problems and little patience for learning new things.
like learning to use a GUI and a Web Interface?
It's not really that people can't use them. It's that they're slow, annoying, hard/impossible to automate, hard/impossible to customize and give you RSI.
We've seen Web interfaces, they're hard to avoid. We've just decided that they're worse.
Could you, for a moment, imagine that others might feel like that about the command-line-plain-text-email-to-mailing-list workflows? Possibly not, as you have labelled them
> the kind of people who have little patience for technology problems and little patience for learning new things
Also tell me how is tolerating rude incumbents of mailing list sending email with 50+ characters in a line a technical problem? (Yes they are often rude, and unwelcoming to those attempting to accept their anachronistic ways. You are demonstrating that specific behaviour right here, which many of us have encountered on those projects.)
I think the projects which accept contributions only from mailing lists will have their contributors die out, or will be forced to change their ways to survive. I for one will never again attempt to contribute to such project, thanks to the inflexibility of the incumbents I have faced several times. Also thanks to the sub-par review workflow, usually the lacking quick CI feedback.
Web UI might give you RSI, but the insufferable email-only-patches people give me PTSD from my previous encounters.
ps: if you are willing to learn new things, you can automate web apps and GUI apps (eg. Autoit, xaut). Some even have proper APIs (COM/dbus/web api), or a cli!
> Possibly not, as you have labelled them
>> the kind of people who have little patience for technology problems and little patience for learning new things
No, I haven't.
You're making an awful lot of shit up about me. All I said is that I've tried the Web UI:s and didn't particularly like them. Speaking of rude.
No, it drives away people who don't want to develop in vim or emacs and prefer to use modern tools instead.
What isn't modern about neovim or emacs 29? Does a tool have to be graphical to be modern?
VSCode actually also supports using git send-email. All you need to do is work on your code in exactly the same way, then use git send-email.
Oh please. Lots of people, myself included, take issue with having to answer your riddles three before I may cross the bridge that you value much more than I do.
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 went from "I find it inconvenient" to "they're masochistic cultists" pretty quickly there. Ad hominem attacks are against site policy.
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.
> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributor
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.
Why would you set it up more than once?
Copy the config, or better yet, version control it (or any of the other solutions to this problem).
There's a psychological basis for people taking pride in a difficult task learned and mastered, and many organizations take advantage of this by creating a culture that rewards this effort when put towards their own products with social status within the organization. It feels manipulative and unethical to me.
(Dare I say HN is one of them, where the effort is a curated form of elitism, and the mechanism up/down votes?)
Like GitHub.
The process tends to be a lot less painful when using git-combine-mailmap [1]
^1
https://git-man-page-generator.lokaltog.net/#Y29tYmluZSQkbWF...
I personally self host git and think that email gives a bunch of advantages:
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.
> 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
You could say the same of GitHub. Why do I need an account on your lil site just to get a patch accepted?
I've used email-based workflow for a few contributions I've made.
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 have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline.
> - 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..
The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me. If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.
A few comments in-line, but I don't want to "sell" anything to you, so just FWIW.
> The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me.
The base system is really, really simple, but there are some common rules/guidelines that just help when working together, and those are required for forge based workflows too (or do you like a single commit touching a dozen completely different, unrelated things, or just no info at all in the commit message, or pull request, for why a change was done).
The core thing from this workflow is using `git send-email --to=mailing@list.example.com <commit-revision>`, the rest are a few details, possible slightly intimidating if viewed from a distant, but each separate and easy to master/implement on it's own – and most are a "set up once, be done thing", so not constant work.
> If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.
As mentioned in another comment: We hired over 15 people in the last year, most of them had no experience with git send-email and mailing list development, but they all accustomed fast and after a few weeks most of them stated they find it nicer (as in simpler, less clutter quicker to do submit own work or review others) - I myself started out over eight years ago at this place, i.e., without much experience in mail based development, and I never ran into bigger problems – on the contrary, this workflow felt like a breadth of fresh air compared to what was I used before (mostly GitHub and GitLab).
Note: this works not only for small to medium, but also is the only way that actually works for the biggest projects in the world (e.g., Linux or QEMU).
Just to be sure: I do not say mail(ing list) based development workflow is Just Perfect™, it sure has its problems and can be improved, and may we get some good web GUIs that tie a few of the components together, currently I see https://sourcehut.org/ as strong contender here.
I read this, and it's like, sure, you could do all of this shit. But you could also just choose a better system outright.
This "shit" (which take is not much though, most of it you do once and as you're probably already using email, using a good mail user agent will help you in other ways too. And I only wrote that "much" to answer to every point of OP, it's a few lines – attention span really has gone down hill.
And what better system? Git(Hu|La)b et al.? Yeah no, you definitively didn't use either much in a collaborative way to just call them better, besides being centralized locked-in. Or what's actually better there? I'd love to hear actual arguments and experiences from someone collaborating with hundreds of other people on a project on these Labs/Hubs, not some hand waved name-calling that adds exactly nothing.
GitHub, while far from perfect, offers a way better issue tracker than mailing lists.
> You can use tools like public-inbox or lei
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.
I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool!
Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!
Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_.
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)
One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications.
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)
I live in my email client and only use GitHub's email notifications. When I was working at GitHub and watching Homebrew/homebrew-core: I would regularly get >1000 a day.
I still do not miss the days of doing patch management from my email client :)
When you treat your inbox as a work queue and aim for zero, it's easy to be productive from within your inbox
I think the focus of attention that this workflow offers certainly has its advantages. There's likely a variety of factors at play, however!
> This is why for certain projects you can be entirely useful even if you can’t code; just as an intermediary
Argitrage?
> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.
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.
Spent a long time not even knowing you can resolve merges in github. All I knew was magit and smerge, and assumed people with the fancier editors had something similar.
> Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge.
I know because I also actually did this.
You still had to do this locally and then turn it into an email and had no real indication whether someone else had seen/tried/reviewed/etc. it
> However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better.
I can totally believe for you: this is the case. For most people, though: it will not be. Feel free to prove me wrong by creating a(nother) project that gets thousands of contributors entirely through email.
(If you're actually Linus Torvalds, though: you win, I'll shut up now)
I had the exact opposite experience.
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 )
You were a github consumer.
You are now a git user.
Ha! I love your bias disclaimer -- and you have certainly brought Homebrew out of the darkages (no disparagement to the earlier works); it's noticeably more performant lately. :)
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. :)
Thanks for the kind words!
> As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t.
Eh, maybe it was, maybe it wasn't! I didn't do any meaningful open source contribution until the tail end of university/college.
> 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.
A great idea and always worth considering <3
I've been contributing to open source projects since the late 90s. I never found the mailing list workflow awful. I also don't find merging/rebasing/resolving conflicts to be much of an issue, and I say this as someone who spent a couple years keeping my company's fork of Chromium rebased on-top of Chromium. Okay, that was a bit of a pain, especially when a new engineer joined Chromium and decided they just had to refactor an entire subsystem.
> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.
Wait, are people doing this via the GitHub web UI these days? That sounds like a nightmare.
You can do some of this through the GitHub web UI and sometimes I do that.
I didn't say that, though, so I'm not sure where you're coming from here.
Ah, so it's more about having a git remote to run `git pull` or `git rebase` against than the forge-specific stuff.
> Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email!
Very poetic, but also not much different to the current state. Just clicking to open a PR instead of sending an email attachment.
:) Thank you!
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 know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.
Thanks for sharing. GitLab team member here.
More GitLab push options are documented in https://docs.gitlab.com/ee/user/project/push_options.html
You can also add a parameter to merge the merge request when the pipeline succeeds. This can be handy for quick fixes that do not require reviews, and avoids unnecessary context switches.
# mwps BRANCHNAME
alias mwps='git push -u origin -o merge_request.create -o merge_request.target=main -o merge_request.merge_when_pipeline_succeeds'
Example from https://gitlab.com/sytses/dotfiles/-/blob/master/git/aliases... and https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks...
If you prefer deeper CLI integration, suggest installing the GitLab CLI: https://docs.gitlab.com/ee/editor_extensions/gitlab_cli/
GitHub has a CLI https://cli.github.com/manual/gh_pr_create
Yes, but the advantage with the "push options" is that I can put it in my .gitconfig and it just works automatically when I do a git push without using some proprietary platform's cli.
correct. Opening a PR triggers an email. No difference at all.
Many oss projects still do this, don't they. I am subscribed to debian and python mail lists. Debian's lists are highly active.
I guess there must be a reason for that! It could just be most are used to that way, but I'd like to believe it's somehow "better"! haha :)
E.g. GCC does it by mail.
sr.ht does that
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.
This is my experience as well. I love the hacker culture associated with it and it's very fun to use e.g. Mutt, sr.ht, and git-send-email together, but it's anything but efficient and straightforward. I ultimately moved away from sr.ht for that reason.
Some, like myself, find the mouse really painful to use and hate graphical interfaces when you have to randomly click to find something (while you can read a man page, grep through it and then automatize the process in custom scripts).
But it is not only about efficiency. It is about control and centralisation.
Git-send-mail works everywhere there’s an email. It allows people to use the tool they prefer. It allows them to build custom tools. It doesn’t make people dependent from a forge (you are a simple "git remote set-url" away from using a new forge).
Github forces everybody to use the same graphical interface which requires tons of JS and lot of CPU. Github forces you to accept all their changes. Github forces you to be a slave of Microsoft and contribute all your code to their IA training set. Github forces you to be notificed of stuff you don’t care.
The "Hacker culture" is first and foremost about personal freedom. And if you believe the tool are not efficient, as a true hacker, you will built others (but, spoiler, most of the time, when you become proficient enough to build you own tools, you realize how efficient the existing ones are).
Hacking is like walking. You look at walkers and you think it looks tiring to walk. So you go to the parking lot. You start your car. You go through the gate and give your driver license to the cop controlling you. You then go to the gas station. You pay with you credit card. There’s an accident in front of you, you are stuck in the traffic. You take your Google controlled GPS and ask for another itinerary. You drive. You wait at a red light, looking at your phone. A notification to pay the insurance of the car. Another one to pay for the leasing of the car itself. A light blink on the dashboard: you need to add oil and do the annual checkup of the car. You drive, you are a bit stressed and go too fast. You see a flash. Shit! Will I get a ticket? I was not that fast? You arrive at destination. There’s no room left in the parking. You start to drive around, hoping for a spot. There! You get it. It is bit small. You hope that nobody will scratch your car. For whatever reason, you learned that cars can’t be scratched so you are very careful. You get out of the car and walk a bit to the destination. Then you see them… The walkers. They went here by foot, through a path in the forest. They are smiling, even if they was some light rain.
And you ask them:
"Why don’t you guys get a car? Seriously? Walking is hard and inefficient. I can’t walk myself for than 1km before getting my legs sore."
> … GitHub forces you to be a slave of Microsoft … Relax, the hyperbole is out of control here. I use GitHub and am certainly not a slave.
I think the value of alternate communication systems is not to be underestimated. And bravo for recalling the heartfelt connection between personal freedom and hacker culture! You are certainly "walking the walk!" :)
I really don't disagree with you at all. I also don't like GitHub anymore nor have I ever liked Microsoft (see my last few comments on HN on recent threads, in fact).
I don't blame anyone for using it either, just didn't fit my personal workflow like mouse-based doesn't fit yours.
This is honestly the best analogy.
I contributed to a project using this, once. I decided that unless I’m highly invested, it’s just not worth the hassle.
This site seems to be made by Drew DeVault who also runs sourcehut.
Didn’t notice that.
But makes sense.
If it was so long ago, it likely predates git, and was more painful than it is now.
(Git was introduced in 2005, while Linux was first released in 1991; fourteen years separate them.)
Indeed, you're right! Yet people still sent patches over email back then, and that is what I meant with "this was how they did it"! :)
AFAICT projects like OpenBSD still use the same infra: emailed patches and CVS (!).
Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)
Certainly! For one thing, CVS does not allow for such easy rebases and merges as git, so someone has to read your patch carefully, make certain that it merges cleanly, and otherwise pay more attention. This may result in a slower pace, but also in less breakage and a larger shared understanding.
Nice! Yeah, CVS, I don't know much about it, but your comment reminds me I should check out things outside the git ken! They might just have valuable understandings I need to learn! Thanks for letting me know about it :)
If you decide to expand your horizons, take a look not only at the venerable CVS but also at things like perforce, fossil, and pijul.
Thank you, nine_k, I shall! if I expand my version control horizons, I will be sure to check out those little gems! :)
Not related to Git + git-email. I just want to say that I love the way this website is structured. Also, it renders fast.
It’s miserable on mobile. Confusing unlabeled next button at the bottom of the page, plus an orange next button that seems to do the same thing but sometimes randomly overlaps the content.
Why not have all the content on one page?
I did not test on mobile and maybe it should have all the steps in single page for that aspect ratio (easier to simply scroll). However, for desktop, it was such a beautiful way to guide the reader each step of the way. It was really well done.
> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't.
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`?
The core reason for this is that lots (all?) of "modern" mail user agents (MUA) mess with whitespace in their default configuration, which breaks patches as the indentation is all of and git is confused.
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.
Zipping the patch kind of works around the issue but introduces probable workflow-incompatibilities, maintainers expect the patch itself in the email, not a compressed archive of the patch.
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.
The point is being able to discuss and archive things via email. Using a zip file makes this moot.
That specific workflow precludes reviewing the patch via quoting and making inline comments, which is the normal way to review patches when sending them via email.
I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
That's not true in general. Many mailing lists accept emails from unsubscribed users, some moderate them (requiring moderator approval for the first post), but I don't know of any which outright rejects such emails.
I might be remembering wrong but I think hostapd's list rejects like that.
In any case, even the possibility of such an outcome is not pleasant.
Email-driven contribution systems, no thanks. Why anyone would, in 2023, elect to use email as the backbone for their development processes eludes me.
It’s fantastic once setup. Almost all systems have email notifications, many allowing you to respond from email. if you have an email client that integrates with your editor then it gives you a source of truth for all notifications which you can easily reference.
I enjoy tutorials like this, in the same way and for the same reasons that I enjoy videos where people make cutting tools out of obsidian that they chip by hand.
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.
Personally, I enjoyed using Git with e-mail when Wine still used it. That said, the major improvement of moving to GitLab is that it's now easier to track changesets individually, as there is now a single place to look for a given changeset, rather than having to follow chains of e-mails.
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.
I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.
will show you the mail headers it would have generated (including subject lines, To: and Cc: fields).git send-email --dry-run <commitish>
will create a separate mail-like file for each patch in <tempdir>. Finally,git format-patch -o<tempdir> <committish>
will (I think) generate something which something capable of reading mbox'es should be able to read. (The latter I may be remembering incorrectly, but worth giving a try.)git format-patch --stdout <committish> > foo.mboxIf you just want to preview the patch itself you can generate it and preview/test use it by doing "git diff > my-own-patch.patch", which would be identical to the patch that "git send-email" would attach to your email. You can apply it with "git apply my-own-patch.patch" for example.
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.
I've found a way to "preview" emails without too much preparatory hassle, at least on Gmail that allows adding suffixes to your address after a + sign. After you finish writing the email, rewrite all the addresses in the To: and Cc: lines so instead of pointing to foo@example.com, they point to myaddress+foo+example.com@gmail.com. Then, once you send it, you can check the version in your inbox to make sure everything is correct, and undo the rewrite to send the email for real.
Just dropping this gem of a talk[1], for the uninitiated. There is a place for this, even if people in the thread have never seen it.
Amending commits, while having the advantage of keeping the git tree pristine at every single point, is incredibly uncomfortable for async workflows such as the one suggested, where your review might take hours/days and you want to continue coding in a forked branch. Upstreaming any code review changes becomes a pain as git treats the two branches as completely distinct.
That is a pain, but the --update-refs argument to git-rebase helps somewhat: https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
Shown to HN on April 2019: https://news.ycombinator.com/item?id=19574257
Is there any collaboration tool (reviews, etc.) that uses git itself to sync the status? Adding email or whatever seems unnecessary, and github et al. seem contrary to the spirit of git.
In theory modern Gerrit supports this, by storing review metadata in Git notes attached to the repository. Most of the time though, people still use the Web UI.
off topic, but why does the page (step 2) rant about protonmail?
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.
Proton Mail Bridge normalizes line breaks in plaintext emails to conform with cleartext PGP signing rules. This sometimes creates problems with third-party cleartext signing which is used by programs such as git-send-email. Third-party signing is not actually a supported use case of the Bridge and this can be worked around by requesting a SMTP submission token.
The world has moved on. Products like Github and Gitlab supercharge these capabilities so far beyond what the Linux Core team are doing with their email lists.
Oh, I thought this was like a PR notification system, it's to actually send the diff to an email list. And the recipients would pull in those changes from the email? I think that's kind of how things worked a long time ago IIRC. Is the goal that this would be as official as how we push to remote, then file a PR now?
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.
One thing this is missing is cover letters for longer series. Last time I checked that was the biggest pain: the fact that there's no real convenient way to store the cover letters; `git send-email --cover` will expect you to compose a new one every time.
This is the fediverse they want
Please do not contribute to this silly archaic practice. It was once not silly. It is now archaic, and it is silly to do it now that we have vastly superior tools.
Weird way to list and sort OSs there.
Microsoft Windows but last, due to the W I guess but macOS has no Apple in it.
The official name of the operating system built by Microsoft is Microsoft Windows. For the OS developed by Apple it's macOS. These are their actual names, this has no personal bias in it.
I think manojlds point is why the OS names are not sorted by the first word in their name as opposed to the last word in their name. Microsoft Windows should have come right after macOS, if the list was sorted alphabetically by first word, then last. It must be sorted by last, then first though. I guess it is a bit of a strange choice since most OS distributions seem to have a single word for their name, making Microsoft Windows appear miss-sorted.
Windows is 100% in the bottom not because of the name but because it is proprietary. The author of the website (Drew DeVault) is a devout FOSS proponent.
Makes sense, objectively it's also the worst OS.
If the whole list was sorted last, then first, "Alpine Linux" wouldn't appear first.
You are right. Thank you for pointing that out.
The author of the website not only made this tutorial but also ranked the OS's according to his preference too!
Windows deserves being at the bottom
Too bad google has disabled "insecure apps" meaning I have a couple of ffmpeg patches sitting around because I haven't yet migrated it to my own domain. I thinking of sending from "FuckYouGoogle".
If this caused more folks to jump ship away from letting Google read all of their messages (as well as mine from the other end), then I’m all for it.
Seems like you're sending plain text emails, no? I have links for websites, resume etc. in the signature so I am not sure how this is conducive to that. Unless there is a method to add a signature with links?
There are lots of reasons to go plain text only, and stripping links and images from signatures is often in the top 10.
That's fair, the links I put in mine are to my lab and own websites. I am not aware of any better way to share that info other than maybe tiny urls.
Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.
You could do it in a branch if you want to, doesn't matter, as long as the diff/patch is based on the branch where upstream does its main work.
This is so absurd. The complexity of this setup is off the charts. If you thought memorizing terrible inconsistent git commands was bad enough, this just cranks it to 11
Not really a huge fan of this whole method, but the GitHub CLI is really well thought out and means I basically never need to leave the terminal if I don't want to.
> but the GitHub CLI is really well thought
How do you get to that conclusion?
The GitHub CLI is a completely different tool than the git CLI
How will that CLI work when using non-proprietary Git (or other VCS) servers? Sounds like a way to get stuck in walled garden.
Each command is sooooo slow though compared to offline synced mail
It is way faster and easier for me to just open up my email client, attach a patch, and send it.