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.
## Send your patches to the mailing list
Changes to Notmuch are contributed as [emailed
-patches](http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project).
+patches](http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Public-Project-over-Email).
Once you have your changes ready in your local repository, you need to
send them to the Notmuch mailing list. The simplest way is to use `git
send-email` to send the patches directly from your repository:
Notmuch project uses [nmbug](http://notmuchmail.org/nmbug/) for
tracking. The Notmuch developers will tag your patches too, making
them show up in the
-[nmbug status page](http://nmbug.tethera.net/status/), but requesting
+[nmbug status page](http://nmbug.notmuchmail.org/status/), but requesting
access and tagging your patches yourself will be helpful in the long
run.