-At the beginning of your email, use as many lines as you wish to
-describe the patch. This text is copied directly into the SCM
-(i.e. git) changelog.
-
-Include comments and other data (such as diffstat) you don't wish to
-be in the changelog following a `---` terminator line. The
-terminator must be on a line by itself.
-
-If you run `git log` on your cloned notmuch repository you see how log
-messages get structured from Subject: line and body contents. One
-description line, one empty line and then, usually multiline description
-following. Conversely, notmuch-wiki git log messages are often just one
-line long -- as the description (and the reasoning for it) is usually
-the content itself.
-
-## 3. Email body contents: patch
-
-### Sub-Rule Number One:
-
-Patches must be reviewable in a standard Linux email client. This
-means in particular, no compression and no base64
-encoding. Attachments are discouraged, but some corporate mail systems
-provide no other way to send patches.
-
-### Sub-Rule Number Two:
-
-Patch must be apply-able by a script that has no knowledge of [MIME]
-encoding. You must make sure your mailer does not escape standard
-US-ASCII characters, wrap long lines, or encode plaintext patches in
-base64 (or any other encoding).
-
-### Sub-Rule Number Three:
-
-Patch must be rooted one level above notmuch source tree. i.e.
-
- diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
- index 556d2bf..274c5da 100644
- --- a/emacs/notmuch-mua.el
- +++ b/emacs/notmuch-mua.el
-
-or in other words, the patch must be apply-able using
-
- patch -sp1 < foo.patch
-
-## 4. One patch per email
-
-This cannot be stressed enough. Even when you are resending a change
-for the 5th time, resist the urge to attach 20 patches to a single
-email. If you do send multiple emails, make sure the second and
-subsequent emails are sent as replies to the first, to keep them all
-together in a thread.
-
-The mailing list archive & the above link to linux patch formatting
-guidelines are good source of information how to format more complex
-subject line for set of related patches.
-
-## 5. Sign your work
-
-( currently notmuch in use )
-
-## 6. Avoid attachments and MIME
-
-Attachments make it more difficult to review and comment on your
-patches. MIME (the mechanism by which files are attached to an email)
-has historically created a problem for patch import scripts. Some
-unfortunate email programs insist upon base64 encoding for all
-attachments, which completely shrouds the patch to some scripts and
-mailers.
-
-## 7. Follow these instructions even when resending
-
-Quite often, when a patch receives comments, the patch author will
-(deep in an email thread) include a revised version of their patch but
-omit the email subject one-line summary, and overall patch
-description. This isn't script friendly, and requires the patch
-description to be hand-edited.
-
-For more details, read Documentation/SubmittingPatches
-in the linux kernel source tree.
-
-
-## Tips for producing and sending your patches.