8 ms·

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 p

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).

ligurio 3y ago
> 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.
- severus_snape 3y ago
  There is usually no need to subscribe.
  - nolist_policy 3y ago
    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.
    - kazinator 3y ago
      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.html https://marc.merlins.org/netrants/reply-to-still-harmful.htm...
    - rurban 3y ago
      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.
- diggan 3y ago
  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 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.
  - stefan_ 3y ago
    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.
    - b112 3y ago
      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!
  - IshKebab 3y ago
    How is that harder than signing up to Github?
    - zanecodes 3y ago
      I only have to sign up to Github once, not once per project.
      - toastal 3y ago
        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).
jorvi 3y ago
> 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.
- severus_snape 3y ago
  For most channels you don't need an IRC account. And there are web interfaces like https://web.libera.chat/ https://web.libera.chat/. I'm trying to subscribe to Discord. I'm currently stuck in a captcha loop.
  - pxc 3y ago
    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...).
- notpachet 3y ago
  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.)
  - LudwigNagasena 3y ago
    “Obfuscated complexity” aka good UX that decreases friction and increases velocity.
    - 3y ago
bastardoperator 3y ago
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.
- delusional 3y ago
  Isn't this also the case for centralized git servers? Even moreover if you run a monorepo.
  - bastardoperator 3y ago
    No clue, I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals.
    - yjftsjthsd-h 3y ago
      > I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals. Like a mail server?
      - bastardoperator 3y ago
        I don't know, sending sensitive information over plain text doesn't scream security to me. So no, unlike a mail server.
        yjftsjthsd-h 3y ago
        It's 2023; mail servers have been using TLS for a very long time.
        bastardoperator 3y ago
        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.
Galanwe 3y ago
No thank you. Avoiding email based workflows and alerting is one of my top priority in every job I have had.
mvdtnz 3y ago
> 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.
- silverfox17 3y ago
  'Arcane terminal commands'? These are standard basic terminal commands.
- felurx 3y ago
  The thing that differs by OS is the installation of Git.
  - mvdtnz 3y ago
    Is this installing git? sudo -H cpan Net::SMTP::SSL IO::Socket::SSL
- ravi-delia 3y ago
  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.

ligurio 3y ago

> 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.

severus_snape 3y ago
There is usually no need to subscribe.
- nolist_policy 3y ago
  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.
  - kazinator 3y ago
    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.html https://marc.merlins.org/netrants/reply-to-still-harmful.htm...
  - rurban 3y ago
    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.
diggan 3y ago
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 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.
- stefan_ 3y ago
  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.
  - b112 3y ago
    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!
- IshKebab 3y ago
  How is that harder than signing up to Github?
  - zanecodes 3y ago
    I only have to sign up to Github once, not once per project.
    - toastal 3y ago
      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).

jorvi 3y ago

> 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.

severus_snape 3y ago
For most channels you don't need an IRC account. And there are web interfaces like https://web.libera.chat/ https://web.libera.chat/. I'm trying to subscribe to Discord. I'm currently stuck in a captcha loop.
- pxc 3y ago
  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...).
notpachet 3y ago
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.)
- LudwigNagasena 3y ago
  “Obfuscated complexity” aka good UX that decreases friction and increases velocity.
  - 3y ago

bastardoperator 3y ago

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.

delusional 3y ago
Isn't this also the case for centralized git servers? Even moreover if you run a monorepo.
- bastardoperator 3y ago
  No clue, I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals.
  - yjftsjthsd-h 3y ago
    > I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals. Like a mail server?
    - bastardoperator 3y ago
      I don't know, sending sensitive information over plain text doesn't scream security to me. So no, unlike a mail server.
      - yjftsjthsd-h 3y ago
        It's 2023; mail servers have been using TLS for a very long time.
        bastardoperator 3y ago
        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.

Galanwe 3y ago

No thank you. Avoiding email based workflows and alerting is one of my top priority in every job I have had.

mvdtnz 3y ago

> 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.

silverfox17 3y ago
'Arcane terminal commands'? These are standard basic terminal commands.
felurx 3y ago
The thing that differs by OS is the installation of Git.
- mvdtnz 3y ago
  Is this installing git? sudo -H cpan Net::SMTP::SSL IO::Socket::SSL
ravi-delia 3y ago
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.