Configuring Email Clients for Patch Submission

| 'git imap-send', etc), and the patches will not be mangled. Approach #3 (external editor) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The following Thunderbird extensions are needed: AboutConfig from https://mjg.github.io/AboutConfig/ and External Editor from https://globs.org/articles.php?lng=en&pg=8 1. Prepare the patch as a text file using your method of choice. 2. Before opening a compose window, use Edit->Account Settings to uncheck the "Compose messages in HTML format" setting in the "Composition & Addressing" panel of the account to be used to send the patch. 3. In the main Thunderbird window, 'before' you open the compose window for the patch, use Tools->about:config to set the following to the indicated values: + ---------- mailnews.send_plaintext_flowed => false mailnews.wraplength => 0 ---------- 4. Open a compose window and click the external editor icon. 5. In the external editor window, read in the patch file and exit the editor normally. Side note: it may be possible to do step 2 with about:config and the following settings but no one's tried yet. ---------- mail.html_compose => false mail.identity.default.compose_html => false mail.identity.id?.compose_html => false ---------- There is a script in contrib/thunderbird-patch-inline which can help you include patches with Thunderbird in an easy way. To use it, do the steps above and then use the script as the external editor. KMail ~~~~~ This should help you to submit patches inline using KMail. 1. Prepare the patch as a text file. 2. Click on New Mail. 3. Go under "Options" in the Composer window and be sure that "Word wrap" is not set. 4. Use Message -> Insert file... and insert the patch. 5. Back in the compose window: add whatever other text you wish to the message, complete the addressing and subject fields, and press send. BASE TREE INFORMATION --------------------- The base tree information block is used for maintainers or third party testers to know the exact state the patch series applies to. It consists of the 'base commit', which is a well-known commit that is part of the stable part of the project history everybody else works off of, and zero or more 'prerequisite patches', which are well-known patches in flight that is not yet part of the 'base commit' that need to be applied on top of 'base commit' in topological order before the patches can be applied. The 'base commit' is shown as "base-commit: " followed by the 40-hex of the commit object name. A 'prerequisite patch' is shown as "prerequisite-patch-id: " followed by the 40-hex 'patch id', which can be obtained by passing the patch through the `git patch-id --stable` command. Imagine that on top of the public commit P, you applied well-known patches X, Y and

This section provides instructions on how to configure various email clients, including Thunderbird and KMail, to submit patches inline without mangling them, and also explains the concept of base tree information, which is used to provide context for patch series by specifying the base commit and prerequisite patches.