Every patch should (must!) contain only one bugfix or new feature.
-Eric S. Raymond has written good 'Software Release Practice HOWTO'.
+Eric S. Raymond has written good
+[Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/).
Check what he has to say about this issue.
## Prepare patches for e-mail submission
-If you're made just one commit (containing just one bugfix or new feature)
+If you've made just one commit (containing just one bugfix or new feature)
you can run
git format-patch HEAD^
you can check with `git log` a 40-char commit-sha1 of the last commit
*since* you want to generate patch files. When you enter
- git format patch commit-sha1(-prefix)
+ git format-patch <commit-sha1(-prefix)>
every commit *after* that commit-sha1 will be used to generate
patch files...
-## Using git send-email to send patches.
+## Sending patches
-If you try to execute `git send-email` and you'll get
+### Using git send-email
+
+(This is the preferred way)
+
+If you try to execute `git send-email` and you get
git: 'send-email' is not a git command. See 'git --help'.
In this phase you can "streamline" your `git send-email` options for
actual patch sending to the mailing list.
-## Sending one patch using compatible (emacs) email client.
+### Sending one patch using compatible (emacs) email client.
+
+Sometimes using git-send-email is not possible; It is not installed by
+default and you don't have privileges to install it or you are not
+able to compile it as it has more build-time requirements as git itself.
One alternative way to send your patches is to use, for example, the
-emacs mail client you've already used to send mails to notmuch mailing list.
+emacs mail client you've already used to send mails to mailing list.
In this case you have to be very careful to keep the patch contents
unchanged:
1. Start composing new mail
-2. Enter notmuch mailing list address to To: field.
+2. Enter notmuch mailing list address into To: field.
3. Go to the body part of the email