The Notmuch source code is maintained in [git](http://git-scm.com/). Get the
source code using:
- git clone git://notmuchmail.org/git/notmuch
+ git clone git://notmuchmail.org/git/notmuch
This guide assumes a working knowledge of git. There are plenty of resources
available on git, such as [Pro Git](http://git-scm.com/book) and the git man
Notmuch git master. There are plenty of ways to work in git, and this
is not your git guide, but a typical workflow might start with:
- git fetch origin
- git checkout -b my-local-branch origin/master
- # make changes
- git add ...
- git commit
+ git fetch origin
+ git checkout -b my-local-branch origin/master
+ # make changes
+ git add ...
+ git commit
If you're planning big changes, it may be advisable to __not__ polish
the patch series according to all the details described below at
build and the tests should pass after each commit. Changes to lib,
cli, emacs, tests, man pages, or news are usually best kept
separate. Also separate cleanups from functional changes. See the
-Notmuch source history (`git log`) for examples.
+Notmuch source history (**`git log`**) for examples.
For in-depth discussion on the subject, see
[Software Release Practice HOWTO](http://tldp.org/HOWTO/Software-Release-Practice-HOWTO/) by Eric S. Raymond.
on commit guidelines, including commit messages.
It is customary to prefix the subject line with "lib:", "cli:", "emacs:",
-etc. depending on which part of Notmuch the commit is changing. See `git log`
-for examples.
+etc. depending on which part of Notmuch the commit is changing. See
+**`git log`** for examples.
Wrap the lines to about 72 characters.
If you make user visible changes, you should add an entry to the
[`NEWS`](http://git.notmuchmail.org/git/notmuch/blob/HEAD:/NEWS) file.
+## Update command-line completion
+
+If you modify or add new features to the Notmuch command-line tools, it
+would be a nice bonus if you also updated the Notmuch command-line
+completion scripts under the `completion` directory of the Notmuch
+source. Not required, but nice to have, and definitely can be done
+afterwards.
+
## Subscribe to the Notmuch mailing list
While strictly not required, it is advisable to subscribe to the
send them to the Notmuch mailing list. The simplest way is to use `git
send-email` to send the patches directly from your repository:
- git send-email --to notmuch@notmuchmail.org origin/master
+ git send-email --to notmuch@notmuchmail.org origin/master
An alternative is to do this in two steps; first generating patch
files (using `git format-patch`), and then sending the patch files to
the mailing list (using `git send-email` or a mail client):
- git format-patch origin/master
- git send-email --to notmuch@notmuchmail.org *.patch
+ git format-patch origin/master
+ git send-email --to notmuch@notmuchmail.org *.patch
Either way, using `git send-email` to actually send the patches is
recommended. It may be distributed separately from git, typically in a
current master.
Once you have the updated series ready, send it to the mailing list
-again. It will be helpful for others to use the
-`--subject-prefix="PATCH vN"` option of `git format-patch` or
-`git send-email` to add a version number of the patch series to the
-subject (replacing vN with v2, v3, etc.) Use a cover letter (or, in
-the case of a single patch, the notes after a "---" at the end of the
-commit message) to summarize the main changes since the previous
-version of the patch series. Also include the message-id reference of
-the previous version.
+again. It will be helpful for others to use the `-vN` option of `git
+format-patch` or `git send-email` to add a version number of the patch
+series to the subject (replacing vN with v2, v3, etc.) Use a cover
+letter (or, in the case of a single patch, the notes after a "---" at
+the end of the commit message) to summarize the main changes since the
+previous version of the patch series. Also include the message-id
+reference of the previous version.
Using the `--in-reply-to` option of `git format-patch` or
`git send-email` to send the patch series as a reply to the earlier
Even better, send a patch adding a "known broken" test to the test suite
highlighting the issue.
+## Update the Notmuch website
+
+Update the Notmuch website, especially if you've landed a commit that
+changes or obsoletes information on the site. It's a wiki; see the
+[[instructions on how to edit the wiki|wikiwriteaccess]].
+
## Join the Notmuch IRC channel
Patch review happens on the Notmuch mailing list, but there is plenty of