Documentation/process/email-clients.rst

Source file repositories/reference/linux-study-clean/Documentation/process/email-clients.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/email-clients.rst
Extension
.rst
Size
12753 bytes
Lines
369
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _email_clients:

Email clients info for Linux
============================

Git
---

These days most developers use ``git send-email`` instead of regular
email clients.  The man page for this is quite good.  On the receiving
end, maintainers use ``git am`` to apply the patches.

If you are new to ``git`` then send your first patch to yourself.  Save it
as raw text including all the headers.  Run ``git am raw_email.txt`` and
then review the changelog with ``git log``.  When that works then send
the patch to the appropriate mailing list(s).

General Preferences
-------------------

Patches for the Linux kernel are submitted via email, preferably as
inline text in the body of the email.  Some maintainers accept
attachments, but then the attachments should have content-type
``text/plain``.  However, attachments are generally frowned upon because
it makes quoting portions of the patch more difficult in the patch
review process.

It's also strongly recommended that you use plain text in your email body,
for patches and other emails alike. https://useplaintext.email may be useful
for information on how to configure your preferred email client, as well as
listing recommended email clients should you not already have a preference.

Email clients that are used for Linux kernel patches should send the
patch text untouched.  For example, they should not modify or delete tabs
or spaces, even at the beginning or end of lines.

Don't send patches with ``format=flowed``.  This can cause unexpected
and unwanted line breaks.

Don't let your email client do automatic word wrapping for you.
This can also corrupt your patch.

Email clients should not modify the character set encoding of the text.
Emailed patches should be in ASCII or UTF-8 encoding only.
If you configure your email client to send emails with UTF-8 encoding,
you avoid some possible charset problems.

Email clients should generate and maintain "References:" or "In-Reply-To:"
headers so that mail threading is not broken.

Copy-and-paste (or cut-and-paste) usually does not work for patches
because tabs are converted to spaces.  Using xclipboard, xclip, and/or
xcutsel may work, but it's best to test this for yourself or just avoid
copy-and-paste.

Don't use PGP/GPG signatures in mail that contains patches.
This breaks many scripts that read and apply the patches.
(This should be fixable.)

It's a good idea to send a patch to yourself, save the received message,
and successfully apply it with 'patch' before sending patches to Linux
mailing lists.


Some email client (MUA) hints
-----------------------------

Here are some specific MUA configuration hints for editing and sending
patches for the Linux kernel.  These are not meant to be complete
software package configuration summaries.

Annotation

Implementation Notes