4 ms·

I have written a guide for emailing patches: https://git-send-email.io https://git-send-email.io And also for configuring your client for plaintext, which is

I have written a guide for emailing patches: https://git-send-email.io https://git-send-email.io And also for configuring your client for plaintext, which is strongly preferred by most mailing lists: https://useplaintext.email https://useplaintext.email If you or anyone else reading this is ever anxious about making mistakes in their early posts on a mailing list, feel free to send the email you'd like to write to me first - sir@cmpwn.com - and I'll look it over and make any suggestions if necessary.

matheusmoreira 6y ago
I've read both, they're amazing resources. Thank you for creating these sites. What I don't understand is how the mailing list itself works. When I want to start a thread, I send an email to the list. When I want to reply to someone, do I email the list or the person? How do I make sure the emails are threaded properly? During my first mailing list interaction I ended up emailing another developer directly somehow. The git email client seems to have support for message IDs. They seem to work just like post identifiers in forums. Mail clients like mutt let users actually edit the email's headers and include metadata like that. I'm not sure if gmail does it behind the scenes. Also, gmail has moved on to newer authentication mechanisms. Is there a simple plain text email client with native support for this? Mutt apparently requires an external program which is seemingly unmaintained.
- deleted 6y ago
  [deleted]
- ddevault 6y ago
  >When I want to reply to someone, do I email the list or the person? How do I make sure the emails are threaded properly? Most people will (and you should, too) use reply-all when participating on a mailing list, which should land the replies straight into your inbox. Just reply-all to these normally, making sure not to top post. If someone makes a mistake, and you weren't subscribed to the list, the web archives usually have a mailto: link somewhere that you can click to reply to the thread. >The git email client seems to have support for message IDs. You should never have to directly work with message IDs if you're using git-send-email and letting your mail client handle replies. >Also, gmail has moved on to newer authentication mechanisms. They should still have support for SMTP PLAIN authentication unless you use gsuite and your admin has turned it off, if I understand correctly. I have written a mail client which has support for OAUTH, however, which you might find useful: https://aerc-mail.org https://aerc-mail.org I don't use gmail so if you run into problems, please reach out to the appropriate mailing list - I won't know how to help. I would also, of course, strongly recommend that you ditch gmail ASAP.
  - captn3m0 6y ago
    Thunderbird supports Gmail over OAuth.
  - u801e 6y ago
    > You should never have to directly work with message IDs if you're using git-send-email and letting your mail client handle replies. In certain cases, if you want to include a patch in an email reply to an existing patch series (using the scissors delimiter), you would need to use git format-patch and send-email using the in-reply-to option so that the reply ends up in the correct place.
    - ddevault 6y ago
      Yeah, but I disrecommend doing this. Starting a new thread is usually better.
      - u801e 6y ago
        But the purpose of doing that is to provide a suggestion for a change in approach for a given patch. I don't think it would make much sense to start a new thread because you lose the association between the original approach and the modified approach. That said, I haven't seen this particular feature used in the years I've followed the git mailing list, so perhaps it's not commonly used.
- Boulth6 6y ago
  > When I want to reply to someone, do I email the list or the person? Reply to person, CC the list. > How do I make sure the emails are threaded properly? Using In-Reply-To header that references parent Message-ID. Git asks for it when sending a patch.
  - ddevault 6y ago
    I disrecommend using In-Reply-To when sending a revised patchset. Just start a new thread. Mailing lists which prefer In-Reply-To are in the minority.
    - u801e 6y ago
      The git mailing list seems to be a mix between the two and their submitting patches document doesn't seem to indicate which convention is preferred. Which mailing lists recommend against using the In-Reply-To header referencing the previous cover letter?
      - ddevault 6y ago
        All lists on lists.sr.ht, for one. Using the In-Reply-To header requires foreknowledge of email headers, the purpose of Message-ID, and how to find it. It's not very approachable. Most mailing lists who have thought about it don't ask users to do it.
Jaruzel 6y ago
What I'd like to see is a way to turn on plaintext email replies only for certain recipients. I know you can't do that in Outlook it's a global setting or nothing - can any other (non-cloud) email client do it?
- ddevault 6y ago
  You really shouldn't send plaintext emails to anyone at all. It's rude.
  - webmaven 6y ago
    > You really shouldn't send plaintext emails to anyone at all. It's rude. Is this sarcasm? Because I know folks that consider anything but plain text emails to be rude.
    - ddevault 6y ago
      Erp, it was a typo. Sending HTML emails to anyone is rude.
  - Jaruzel 6y ago
    To people, I agree. But we're talking mailing lists here, where plaintext is preferred.
- gpanders 6y ago
  mutt can probably do something like this with its send-hook [1] feature. Another alternative is to send emails as multipart/alternative with a plaintext part and an HTML part. That way, recipients who use an HTML email client will see the HTML and plaintext readers will see plaintext. This is what I do at work. My work uses Outlook which does not support format=flowed [2], meaning my plaintext emails would look weird to colleagues who use the standard Outlook settings. Outlook will also default to responding in plaintext to a plaintext email. To avoid forcing my preferences on my colleagues, I now use an automatic filter [3] to convert my plaintext emails into HTML using a Markdown parser. My email client then sends both parts: the HTML and plaintext part as a multipart/alternative email. [1]: http://www.mutt.org/doc/manual/#send-hook http://www.mutt.org/doc/manual/#send-hook [2]: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html [3]: http://www.mutt.org/doc/manual/#send-multipart-alternative-filter http://www.mutt.org/doc/manual/#send-multipart-alternative-f...

matheusmoreira 6y ago

I've read both, they're amazing resources. Thank you for creating these sites. What I don't understand is how the mailing list itself works. When I want to start a thread, I send an email to the list. When I want to reply to someone, do I email the list or the person? How do I make sure the emails are threaded properly? During my first mailing list interaction I ended up emailing another developer directly somehow. The git email client seems to have support for message IDs. They seem to work just like post identifiers in forums. Mail clients like mutt let users actually edit the email's headers and include metadata like that. I'm not sure if gmail does it behind the scenes. Also, gmail has moved on to newer authentication mechanisms. Is there a simple plain text email client with native support for this? Mutt apparently requires an external program which is seemingly unmaintained.

deleted 6y ago
[deleted]
ddevault 6y ago
>When I want to reply to someone, do I email the list or the person? How do I make sure the emails are threaded properly? Most people will (and you should, too) use reply-all when participating on a mailing list, which should land the replies straight into your inbox. Just reply-all to these normally, making sure not to top post. If someone makes a mistake, and you weren't subscribed to the list, the web archives usually have a mailto: link somewhere that you can click to reply to the thread. >The git email client seems to have support for message IDs. You should never have to directly work with message IDs if you're using git-send-email and letting your mail client handle replies. >Also, gmail has moved on to newer authentication mechanisms. They should still have support for SMTP PLAIN authentication unless you use gsuite and your admin has turned it off, if I understand correctly. I have written a mail client which has support for OAUTH, however, which you might find useful: https://aerc-mail.org https://aerc-mail.org I don't use gmail so if you run into problems, please reach out to the appropriate mailing list - I won't know how to help. I would also, of course, strongly recommend that you ditch gmail ASAP.
- captn3m0 6y ago
  Thunderbird supports Gmail over OAuth.
- u801e 6y ago
  > You should never have to directly work with message IDs if you're using git-send-email and letting your mail client handle replies. In certain cases, if you want to include a patch in an email reply to an existing patch series (using the scissors delimiter), you would need to use git format-patch and send-email using the in-reply-to option so that the reply ends up in the correct place.
  - ddevault 6y ago
    Yeah, but I disrecommend doing this. Starting a new thread is usually better.
    - u801e 6y ago
      But the purpose of doing that is to provide a suggestion for a change in approach for a given patch. I don't think it would make much sense to start a new thread because you lose the association between the original approach and the modified approach. That said, I haven't seen this particular feature used in the years I've followed the git mailing list, so perhaps it's not commonly used.
Boulth6 6y ago
> When I want to reply to someone, do I email the list or the person? Reply to person, CC the list. > How do I make sure the emails are threaded properly? Using In-Reply-To header that references parent Message-ID. Git asks for it when sending a patch.
- ddevault 6y ago
  I disrecommend using In-Reply-To when sending a revised patchset. Just start a new thread. Mailing lists which prefer In-Reply-To are in the minority.
  - u801e 6y ago
    The git mailing list seems to be a mix between the two and their submitting patches document doesn't seem to indicate which convention is preferred. Which mailing lists recommend against using the In-Reply-To header referencing the previous cover letter?
    - ddevault 6y ago
      All lists on lists.sr.ht, for one. Using the In-Reply-To header requires foreknowledge of email headers, the purpose of Message-ID, and how to find it. It's not very approachable. Most mailing lists who have thought about it don't ask users to do it.

Jaruzel 6y ago

What I'd like to see is a way to turn on plaintext email replies only for certain recipients. I know you can't do that in Outlook it's a global setting or nothing - can any other (non-cloud) email client do it?

ddevault 6y ago
You really shouldn't send plaintext emails to anyone at all. It's rude.
- webmaven 6y ago
  > You really shouldn't send plaintext emails to anyone at all. It's rude. Is this sarcasm? Because I know folks that consider anything but plain text emails to be rude.
  - ddevault 6y ago
    Erp, it was a typo. Sending HTML emails to anyone is rude.
- Jaruzel 6y ago
  To people, I agree. But we're talking mailing lists here, where plaintext is preferred.
gpanders 6y ago
mutt can probably do something like this with its send-hook [1] feature. Another alternative is to send emails as multipart/alternative with a plaintext part and an HTML part. That way, recipients who use an HTML email client will see the HTML and plaintext readers will see plaintext. This is what I do at work. My work uses Outlook which does not support format=flowed [2], meaning my plaintext emails would look weird to colleagues who use the standard Outlook settings. Outlook will also default to responding in plaintext to a plaintext email. To avoid forcing my preferences on my colleagues, I now use an automatic filter [3] to convert my plaintext emails into HTML using a Markdown parser. My email client then sends both parts: the HTML and plaintext part as a multipart/alternative email. [1]: http://www.mutt.org/doc/manual/#send-hook http://www.mutt.org/doc/manual/#send-hook [2]: https://joeclark.org/ffaq.html https://joeclark.org/ffaq.html [3]: http://www.mutt.org/doc/manual/#send-multipart-alternative-filter http://www.mutt.org/doc/manual/#send-multipart-alternative-f...