multimail: stop shipping a copy

The multimail project is developed independently and has its own project
page. Traditionally, we shipped a copy in contrib/.

However, such a copy is prone to become stale, and users are much better
served to be directed to the actual project instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 0 insertions, 145 deletions

diff --git a/contrib/hooks/multimail/README.migrate-from-post-receive-email b/contrib/hooks/multimail/README.migrate-from-post-receive-email
deleted file mode 100644
index 1e6a976699..0000000000
--- a/contrib/hooks/multimail/README.migrate-from-post-receive-email
+++ /dev/null
@@ -1,145 +0,0 @@
-git-multimail is close to, but not exactly, a plug-in replacement for
-the old Git project script contrib/hooks/post-receive-email.  This
-document describes the differences and explains how to configure
-git-multimail to get behavior closest to that of post-receive-email.
-
-If you are in a hurry
-=====================
-
-A script called migrate-mailhook-config is included with
-git-multimail.  If you run this script within a Git repository that is
-configured to use post-receive-email, it will convert the
-configuration settings into the approximate equivalent settings for
-git-multimail.  For more information, run
-
-    migrate-mailhook-config --help
-
-
-Configuration differences
-=========================
-
-* The names of the config options for git-multimail are in namespace
-  "multimailhook.*" instead of "hooks.*".  (Editorial comment:
-  post-receive-email should never have used such a generic top-level
-  namespace.)
-
-* In emails about new annotated tags, post-receive-email includes a
-  shortlog of all changes since the previous annotated tag.  To get
-  this behavior with git-multimail, you need to set
-  multimailhook.announceshortlog to true:
-
-      git config multimailhook.announceshortlog true
-
-* multimailhook.commitlist -- This is a new configuration variable.
-  Recipients listed here will receive a separate email for each new
-  commit.  However, if this variable is *not* set, it defaults to the
-  value of multimailhook.mailinglist.  Therefore, if you *don't* want
-  the members of multimailhook.mailinglist to receive one email per
-  commit, then set this value to the empty string:
-
-      git config multimailhook.commitlist ''
-
-* multimailhook.emailprefix -- If this value is not set, then the
-  subjects of generated emails are prefixed with the short name of the
-  repository enclosed in square brackets; e.g., "[myrepo]".
-  post-receive-email defaults to prefix "[SCM]" if this option is not
-  set.  So if you were using the old default and want to retain it
-  (for example, to avoid having to change your email filters), set
-  this variable explicitly to the old value:
-
-      git config multimailhook.emailprefix "[SCM]"
-
-* The "multimailhook.showrev" configuration option is not supported.
-  Its main use is obsoleted by the one-email-per-commit feature of
-  git-multimail.
-
-
-Other differences
-=================
-
-This section describes other differences in the behavior of
-git-multimail vs. post-receive-email.  For full details, please refer
-to the main README file:
-
-* One email per commit.  For each reference change, the script first
-  outputs one email summarizing the reference change (including
-  one-line summaries of the new commits), then it outputs a separate
-  email for each new commit that was introduced, including patches.
-  These one-email-per-commit emails go to the addresses listed in
-  multimailhook.commitlist.  post-receive-email sends only one email
-  for each *reference* that is changed, no matter how many commits
-  were added to the reference.
-
-* Better algorithm for detecting new commits.  post-receive-email
-  processes one reference change at a time, which causes it to fail to
-  describe new commits that were included in multiple branches.  For
-  example, if a single push adds the "*" commits in the diagram below,
-  then post-receive-email would never include the details of the two
-  commits that are common to "master" and "branch" in its
-  notifications.
-
-      o---o---o---*---*---*    <-- master
-                       \
-                        *---*  <-- branch
-
-  git-multimail analyzes all reference modifications to determine
-  which commits were not present before the change, therefore avoiding
-  that error.
-
-* In reference change emails, git-multimail tells which commits have
-  been added to the reference vs. are entirely new to the repository,
-  and which commits that have been omitted from the reference
-  vs. entirely discarded from the repository.
-
-* The environment in which Git is running can be configured via an
-  "Environment" abstraction.
-
-* Built-in support for Gitolite-managed repositories.
-
-* Instead of using full SHA1 object names in emails, git-multimail
-  mostly uses abbreviated SHA1s, plus one-line log message summaries
-  where appropriate.
-
-* In the schematic diagrams that explain non-fast-forward commits,
-  git-multimail shows the names of the branches involved.
-
-* The emails generated by git-multimail include the name of the Git
-  repository that was modified; this is convenient for recipients who
-  are monitoring multiple repositories.
-
-* git-multimail allows the email "From" addresses to be configured.
-
-* The recipients lists (multimailhook.mailinglist,
-  multimailhook.refchangelist, multimailhook.announcelist, and
-  multimailhook.commitlist) can be comma-separated values and/or
-  multivalued settings in the config file; e.g.,
-
-      [multimailhook]
-              mailinglist = mr.brown@example.com, mr.black@example.com
-              announcelist = Him <him@example.com>
-              announcelist = Jim <jim@example.com>
-              announcelist = pop@example.com
-
-  This might make it easier to maintain short recipients lists without
-  requiring full-fledged mailing list software.
-
-* By default, git-multimail sets email "Reply-To" headers to reply to
-  the pusher (for reference updates) and to the author (for commit
-  notifications).  By default, the pusher's email address is
-  constructed by appending "multimailhook.emaildomain" to the pusher's
-  username.
-
-* The generated emails contain a configurable footer.  By default, it
-  lists the name of the administrator who should be contacted to
-  unsubscribe from notification emails.
-
-* New option multimailhook.emailmaxlinelength to limit the length of
-  lines in the main part of the email body.  The default limit is 500
-  characters.
-
-* New option multimailhook.emailstrictutf8 to ensure that the main
-  part of the email body is valid UTF-8.  Invalid characters are
-  turned into the Unicode replacement character, U+FFFD.  By default
-  this option is turned on.
-
-* Written in Python.  Easier to add new features.