git-multimail / git-multimail

Send notification emails for pushes to a git repository (an improved version of post-receive-mail)

git-multimail

git-multimail is a tool for sending notification emails on pushes to a Git repository. It includes a Python module called git_multimail.py, which can either be used as a hook script directly or can be imported as a Python module into another script.

git-multimail is derived from the Git project's old contrib/hooks/post-receive-email, and is mostly compatible with that script. See README.migrate-from-post-receive-email for details about the differences and for how to migrate from post-receive-email to git-multimail.

git-multimail, like the rest of the Git project, is licensed under GPLv2 (see the COPYING file for details).

Please note: although, as a convenience, git-multimail may be distributed along with the main Git project, development of git-multimail takes place in its own, separate project. Please, read CONTRIBUTING.rst for more information.

By default, for each push received by the repository, git-multimail:

1. Outputs one email summarizing each reference that was changed. These "reference change" (called "refchange" below) emails describe the nature of the change (e.g., was the reference created, deleted, fast-forwarded, etc.) and include a one-line summary of each commit that was added to the reference.

2. Outputs one email for each new commit that was introduced by the reference change. These "commit" emails include a list of the files changed by the commit, followed by the diffs of files modified by the commit. The commit emails are threaded to the corresponding reference change email via "In-Reply-To". This style (similar to the "git format-patch" style used on the Git mailing list) makes it easy to scan through the emails, jump to patches that need further attention, and write comments about specific commits. Commits are handled in reverse topological order (i.e., parents shown before children). For example:

   [git] branch master updated
   + [git] 01/08: doc: fix xref link from api docs to manual pages
   + [git] 02/08: api-credentials.txt: show the big picture first
   + [git] 03/08: api-credentials.txt: mention credential.helper explicitly
   + [git] 04/08: api-credentials.txt: add "see also" section
   + [git] 05/08: t3510 (cherry-pick-sequence): add missing '&&'
   + [git] 06/08: Merge branch 'rr/maint-t3510-cascade-fix'
   + [git] 07/08: Merge branch 'mm/api-credentials-doc'
   + [git] 08/08: Git 1.7.11-rc2

   By default, each commit appears in exactly one commit email, the first time that it is pushed to the repository. If a commit is later merged into another branch, then a one-line summary of the commit is included in the reference change email (as usual), but no additional commit email is generated. See multimailhook.refFilter(Inclusion|Exclusion|DoSend|DontSend)Regex below to configure which branches and tags are watched by the hook.

   By default, reference change emails have their "Reply-To" field set to the person who pushed the change, and commit emails have their "Reply-To" field set to the author of the commit.

3. Output one "announce" mail for each new annotated tag, including information about the tag and optionally a shortlog describing the changes since the previous tag. Such emails might be useful if you use annotated tags to mark releases of your project.

Requirements

• Python 2.x, version 2.4 or later. No non-standard Python modules are required. git-multimail has preliminary support for Python 3 (but it has been better tested with Python 2).
• The git command must be in your PATH. git-multimail is known to work with Git versions back to 1.7.1. (Earlier versions have not been tested; if you do so, please report your results.)
• To send emails using the default configuration, a standard sendmail program must be located at '/usr/sbin/sendmail' or '/usr/lib/sendmail' and must be configured correctly to send emails. If this is not the case, set multimailhook.sendmailCommand, or see the multimailhook.mailer configuration variable below for how to configure git-multimail to send emails via an SMTP server.
• git-multimail is currently tested only on Linux. It may or may not work on other platforms such as Windows and Mac OS. See CONTRIBUTING.rst to improve the situation.

Invocation

git_multimail.py is designed to be used as a post-receive hook in a Git repository (see githooks(5)). Link or copy it to $GIT_DIR/hooks/post-receive within the repository for which email notifications are desired. Usually it should be installed on the central repository for a project, to which all commits are eventually pushed.

For use on pre-v1.5.1 Git servers, git_multimail.py can also work as an update hook, taking its arguments on the command line. To use this script in this manner, link or copy it to $GIT_DIR/hooks/update. Please note that the script is not completely reliable in this mode ¹.

Alternatively, git_multimail.py can be imported as a Python module into your own Python post-receive script. This method is a bit more work, but allows the behavior of the hook to be customized using arbitrary Python code. For example, you can use a custom environment (perhaps inheriting from GenericEnvironment or GitoliteEnvironment) to

• change how the user who did the push is determined
• read users' email addresses from an LDAP server or from a database
• decide which users should be notified about which commits based on the contents of the commits (e.g., for users who want to be notified only about changes affecting particular files or subdirectories)

Or you can change how emails are sent by writing your own Mailer class. The post-receive script in this directory demonstrates how to use git_multimail.py as a Python module. (If you make interesting changes of this type, please consider sharing them with the community.)

Troubleshooting/FAQ

Please read doc/troubleshooting.rst for frequently asked questions and common issues with git-multimail.

Configuration

By default, git-multimail mostly takes its configuration from the following git config settings:

multimailhook.environment

This describes the general environment of the repository. In most cases, you do not need to specify a value for this variable: git-multimail will autodetect which environment to use. Currently supported values:

generic

the username of the pusher is read from $USER or $USERNAME and the repository name is derived from the repository's path.

gitolite

Environment to use when git-multimail is ran as a gitolite hook.

The username of the pusher is read from $GL_USER, the repository name is read from $GL_REPO, and the From: header value is optionally read from gitolite.conf (see multimailhook.from).

For more information about gitolite and git-multimail, read doc/gitolite.rst

stash

Environment to use when git-multimail is ran as an Atlassian BitBucket Server (formerly known as Atlassian Stash) hook.

Warning: this mode was provided by a third-party contributor and never tested by the git-multimail maintainers. It is provided as-is and may or may not work for you.

This value is automatically assumed when the stash-specific flags (--stash-user and --stash-repo) are specified on the command line. When this environment is active, the username and repo come from these two command line flags, which must be specified.

gerrit

Environment to use when git-multimail is ran as a ref-updated Gerrit hook.

This value is used when the gerrit-specific command line flags (--oldrev, --newrev, --refname, --project) for gerrit's ref-updated hook are present. When this environment is active, the username of the pusher is taken from the --submitter argument if that command line option is passed, otherwise 'Gerrit' is used. The repository name is taken from the --project option on the command line, which must be passed.

For more information about gerrit and git-multimail, read doc/gerrit.rst

gitea

Environment to use when git-multimail is ran as Gitea or Forgejo post-receive hook.

This environment is detected automatically, and so doesn't need to be explicitly specified, normally. Just copy, or link, git_multimail.py to hooks/post-receive.d subdirectory of of the repository directory (e.g. /var/lib/forgejo/data/forgejo-repositories/org/repo.git).

If none of these environments is suitable for your setup, then you can implement a Python class that inherits from Environment and instantiate it via a script that looks like the example post-receive script.

The environment value can be specified on the command line using the --environment option. If it is not specified on the command line or by multimailhook.environment, the value is guessed as follows:

• If stash-specific (respectively gerrit-specific) command flags are present on the command-line, then stash (respectively gerrit) is used.
• If the environment variables $GL_USER and $GL_REPO are set, then gitolite is used.
• If none of the above apply, then generic is used.

multimailhook.repoName

A short name of this Git repository, to be used in various places in the notification email text. The default is to use $GL_REPO for gitolite repositories, or otherwise to derive this value from the repository path name.

multimailhook.mailingList

The list of email addresses to which notification emails should be sent, as RFC 2822 email addresses separated by commas. This configuration option can be multivalued. Leave it unset or set it to the empty string to not send emails by default. The next few settings can be used to configure specific address lists for specific types of notification email.

multimailhook.refchangeList

The list of email addresses to which summary emails about reference changes should be sent, as RFC 2822 email addresses separated by commas. This configuration option can be multivalued. The default is the value in multimailhook.mailingList. Set this value to "none" (or the empty string) to prevent reference change emails from being sent even if multimailhook.mailingList is set.

multimailhook.announceList

The list of email addresses to which emails about new annotated tags should be sent, as RFC 2822 email addresses separated by commas. This configuration option can be multivalued. The default is the value in multimailhook.refchangeList or multimailhook.mailingList. Set this value to "none" (or the empty string) to prevent annotated tag announcement emails from being sent even if one of the other values is set.

multimailhook.commitList

The list of email addresses to which emails about individual new commits should be sent, as RFC 2822 email addresses separated by commas. This configuration option can be multivalued. The default is the value in multimailhook.mailingList. Set this value to "none" (or the empty string) to prevent notification emails about individual commits from being sent even if multimailhook.mailingList is set.

multimailhook.announceShortlog

If this option is set to true, then emails about changes to annotated tags include a shortlog of changes since the previous tag. This can be useful if the annotated tags represent releases; then the shortlog will be a kind of rough summary of what has happened since the last release. But if your tagging policy is not so straightforward, then the shortlog might be confusing rather than useful. Default is false.

multimailhook.commitEmailFormat

The format of email messages for the individual commits, can be "text" or "html". In the latter case, the emails will include diffs using colorized HTML instead of plain text used by default. Note that this currently the ref change emails are always sent in plain text.

Note that when using "html", the formatting is done by parsing the output of git log with -p. When using multimailhook.commitLogOpts to specify a --format for git log, one may get false positive (e.g. lines in the body of the message starting with +++ or --- colored in red or green).

By default, all the message is HTML-escaped. See multimailhook.htmlInIntro to change this behavior.

multimailhook.commitBrowseURL

Used to generate a link to an online repository browser in commit emails. This variable must be a string. Format directives like %(<variable>)s will be expanded the same way as template strings. In particular, %(id)s will be replaced by the full Git commit identifier (40-chars hexadecimal).

If the string does not contain any format directive, then %(id)s will be automatically added to the string. If you don't want %(id)s to be automatically added, use the empty format directive %()s anywhere in the string.

For example, a suitable value for the git-multimail project itself would be https://github.com/git-multimail/git-multimail/commit/%(id)s.

multimailhook.htmlInIntro, multimailhook.htmlInFooter

When generating an HTML message, git-multimail escapes any HTML sequence by default. This means that if a template contains HTML like <a href="foo">link</a>, the reader will see the HTML source code and not a proper link.

Set multimailhook.htmlInIntro to true to allow writing HTML formatting in introduction templates. Similarly, set multimailhook.htmlInFooter for HTML in the footer.

Variables expanded in the template are still escaped. For example, if a repository's path contains a <, it will be rendered as such in the message.

Read doc/customizing-emails.rst for more details and examples.

multimailhook.refchangeShowGraph

If this option is set to true, then summary emails about reference changes will additionally include:

• a graph of the added commits (if any)
• a graph of the discarded commits (if any)

The log is generated by running git log --graph with the options specified in graphOpts. The default is false.

multimailhook.refchangeShowLog

If this option is set to true, then summary emails about reference changes will include a detailed log of the added commits in addition to the one line summary. The log is generated by running git log with the options specified in multimailhook.logOpts. Default is false.

multimailhook.mailer

This option changes the way emails are sent. Accepted values are:

• sendmail (the default): use the command /usr/sbin/sendmail or /usr/lib/sendmail (or sendmailCommand, if configured). This mode can be further customized via the following options:

  multimailhook.sendmailCommand

  The command used by mailer sendmail to send emails. Shell quoting is allowed in the value of this setting, but remember that Git requires double-quotes to be escaped; e.g.:

  git config multimailhook.sendmailcommand '/usr/sbin/sendmail -oi -t -F \"Git Repo\"'

  Default is '/usr/sbin/sendmail -oi -t' or '/usr/lib/sendmail -oi -t' (depending on which file is present and executable).

  multimailhook.envelopeSender

  If set then pass this value to sendmail via the -f option to set the envelope sender address.

• smtp: use Python's smtplib. This is useful when the sendmail command is not available on the system. This mode can be further customized via the following options:

  multimailhook.smtpServer

  The name of the SMTP server to connect to. The value can also include a colon and a port number; e.g., mail.example.com:25. Default is 'localhost' using port 25.

  multimailhook.smtpUser, multimailhook.smtpPass

  Server username and password. Required if smtpEncryption is 'ssl'. Note that the username and password currently need to be set cleartext in the configuration file, which is not recommended. If you need to use this option, be sure your configuration file is read-only.

  multimailhook.envelopeSender

  The sender address to be passed to the SMTP server. If unset, then the value of multimailhook.from is used.

  multimailhook.smtpServerTimeout

  Timeout in seconds. Default is 10.

  multimailhook.smtpEncryption

  Set the security type. Allowed values: none, ssl, tls (starttls). Default is none.

  multimailhook.smtpCACerts

  Set the path to a list of trusted CA certificate to verify the server certificate, only supported when smtpEncryption is tls. If unset or empty, the server certificate is not verified. If it targets a file containing a list of trusted CA certificates (PEM format) these CAs will be used to verify the server certificate. For debian, you can set /etc/ssl/certs/ca-certificates.crt for using the system trusted CAs. For self-signed server, you can add your server certificate to the system store:

  cd /usr/local/share/ca-certificates/
  openssl s_client -starttls smtp \
         -connect mail.example.net:587 -showcerts \
         </dev/null 2>/dev/null \
       | openssl x509 -outform PEM >mail.example.net.crt
  update-ca-certificates

  and used the updated /etc/ssl/certs/ca-certificates.crt. Or directly use your /path/to/mail.example.net.crt. Default is unset.

  multimailhook.smtpServerDebugLevel

  Integer number. Set to greater than 0 to activate debugging.

multimailhook.from, multimailhook.fromCommit, multimailhook.fromRefchange

If set, use this value in the From: field of generated emails. fromCommit is used for commit emails, fromRefchange is used for refchange emails, and from is used as fall-back in all cases.

The value for these variables can be either:

• An email address, which will be used directly.
• The value pusher, in which case the pusher's address (if available) will be used.
• The value author (meaningful only for fromCommit), in which case the commit author's address will be used.

If config values are unset, the value of the From: header is determined as follows:

1. (gitolite environment only) 1.a) If multimailhook.MailaddressMap is set, and is a path to an existing file (if relative, it is considered relative to the place where gitolite.conf is located), then this file should contain lines like:

   username Firstname Lastname <[email protected]>

   git-multimail will then look for a line where $GL_USER matches the username part, and use the rest of the line for the From: header.

   1.b) Parse gitolite.conf, looking for a block of comments that looks like this:

   # BEGIN USER EMAILS
   # username Firstname Lastname <[email protected]>
   # END USER EMAILS

   If that block exists, and there is a line between the BEGIN USER EMAILS and END USER EMAILS lines where the first field matches the gitolite username ($GL_USER), use the rest of the line for the From: header.

2. If the user.email configuration setting is set, use its value (and the value of user.name, if set).
3. Use the value of multimailhook.envelopeSender.

multimailhook.MailaddressMap

(gitolite environment only) File to look for a From: address based on the user doing the push. Defaults to unset. See multimailhook.from for details.

multimailhook.administrator

The name and/or email address of the administrator of the Git repository; used in FOOTER_TEMPLATE. Default is multimailhook.envelopesender if it is set; otherwise a generic string is used.

multimailhook.emailPrefix

All emails have this string prepended to their subjects, to aid email filtering (though filtering based on the X-Git-* email headers is probably more robust). Default is the short name of the repository in square brackets; e.g., [myrepo]. Set this value to the empty string to suppress the email prefix. You may use the placeholder %(repo_shortname)s for the short name of the repository.

multimailhook.emailMaxLines

The maximum number of lines that should be included in the body of a generated email. If not specified, there is no limit. Lines beyond the limit are suppressed and counted, and a final line is added indicating the number of suppressed lines.

multimailhook.emailMaxLineLength

The maximum length of a line in the email body. Lines longer than this limit are truncated to this length with a trailing [...] added to indicate the missing text. The default is 500, because (a) diffs with longer lines are probably from binary files, for which a diff is useless, and (b) even if a text file has such long lines, the diffs are probably unreadable anyway. To disable line truncation, set this option to 0.

multimailhook.subjectMaxLength

The maximum length of the subject line (i.e. the oneline field in templates, not including the prefix). Lines longer than this limit are truncated to this length with a trailing [...] added to indicate the missing text. This option The default is to use multimailhook.emailMaxLineLength. This option avoids sending emails with overly long subject lines, but should not be needed if the commit messages follow the Git convention (one short subject line, then a blank line, then the message body). To disable line truncation, set this option to 0.

multimailhook.maxCommitEmails

The maximum number of commit emails to send for a given change. When the number of patches is larger that this value, only the summary refchange email is sent. This can avoid accidental mailbombing, for example on an initial push. To disable commit emails limit, set this option to 0. The default is 500.

multimailhook.excludeMergeRevisions

When sending out revision emails, do not consider merge commits (the functional equivalent of rev-list --no-merges). The default is false (send merge commit emails).

multimailhook.emailStrictUTF8

If this boolean option is set to true, then the main part of the email body is forced to be valid UTF-8. Any characters that are not valid UTF-8 are converted to the Unicode replacement character, U+FFFD. The default is true.

This option is ineffective with Python 3, where non-UTF-8 characters are unconditionally replaced.

multimailhook.diffOpts

Options passed to git diff-tree when generating the summary information for ReferenceChange emails. Default is --stat --summary --find-copies-harder. Add -p to those options to include a unified diff of changes in addition to the usual summary output. Shell quoting is allowed; see multimailhook.logOpts for details.

multimailhook.graphOpts

Options passed to git log --graph when generating graphs for the reference change summary emails (used only if refchangeShowGraph is true). The default is '--oneline --decorate'.

Shell quoting is allowed; see logOpts for details.

multimailhook.logOpts

Options passed to git log to generate additional info for reference change emails (used only if refchangeShowLog is set). For example, adding -p will show each commit's complete diff. The default is empty.

Shell quoting is allowed; for example, a log format that contains spaces can be specified using something like:

git config multimailhook.logopts '--pretty=format:"%h %aN <%aE>%n%s%n%n%b%n"'

If you want to set this by editing your configuration file directly, remember that Git requires double-quotes to be escaped (see git-config(1) for more information):

[multimailhook]
        logopts = --pretty=format:\"%h %aN <%aE>%n%s%n%n%b%n\"

multimailhook.commitLogOpts

Options passed to git log to generate additional info for revision change emails. For example, adding --ignore-all-spaces will suppress whitespace changes. The default options are -C --stat -p --cc. Shell quoting is allowed; see multimailhook.logOpts for details.

multimailhook.dateSubstitute

String to use as a substitute for Date: in the output of git log while formatting commit messages. This is useful to avoid emitting a line that can be interpreted by mailers as the start of a cited message (Zimbra webmail in particular). Defaults to CommitDate:. Set to an empty string or none to deactivate the behavior.

multimailhook.emailDomain

Domain name appended to the username of the person doing the push to convert it into an email address (via "%s@%s" % (username, emaildomain)). More complicated schemes can be implemented by overriding Environment and overriding its get_pusher_email() method.

multimailhook.replyTo, multimailhook.replyToCommit, multimailhook.replyToRefchange

Addresses to use in the Reply-To: field for commit emails (replyToCommit) and refchange emails (replyToRefchange). multimailhook.replyTo is used as default when replyToCommit or replyToRefchange is not set. The shortcuts pusher and author are allowed with the same semantics as for multimailhook.from. In addition, the value none can be used to omit the Reply-To: field.

The default is pusher for refchange emails, and author for commit emails.

multimailhook.quiet

Do not output the list of email recipients from the hook

multimailhook.stdout

For debugging, send emails to stdout rather than to the mailer. Equivalent to the --stdout command line option

multimailhook.scanCommitForCc

If this option is set to true, than recipients from lines in commit body that starts with CC: will be added to CC list. Default: false

multimailhook.combineWhenSingleCommit

If this option is set to true and a single new commit is pushed to a branch, combine the summary and commit email messages into a single email. Default: true

multimailhook.refFilterInclusionRegex, multimailhook.refFilterExclusionRegex, multimailhook.refFilterDoSendRegex, multimailhook.refFilterDontSendRegex

Warning: these options are experimental. They should work, but the user-interface is not stable yet (in particular, the option names may change). If you want to participate in stabilizing the feature, please contact the maintainers and/or send pull-requests. If you are happy with the current shape of the feature, please report it too.

Regular expressions that can be used to limit refs for which email updates will be sent. It is an error to specify both an inclusion and an exclusion regex. If a refFilterInclusionRegex is specified, emails will only be sent for refs which match this regex. If a refFilterExclusionRegex regex is specified, emails will be sent for all refs except those that match this regex (or that match a predefined regex specific to the environment, such as "^refs/notes" for most environments and "^refs/notes|^refs/changes" for the gerrit environment).

The expressions are matched against the complete refname, and is considered to match if any substring matches. For example, to filter-out all tags, set refFilterExclusionRegex to ^refs/tags/ (note the leading ^ but no trailing $). If you set refFilterExclusionRegex to master, then any ref containing master will be excluded (the master branch, but also refs/tags/master or refs/heads/foo-master-bar).

refFilterDoSendRegex and refFilterDontSendRegex are analogous to refFilterInclusionRegex and refFilterExclusionRegex with one difference: with refFilterDoSendRegex and refFilterDontSendRegex, commits introduced by one excluded ref will not be considered as new when they reach an included ref. Typically, if you add a branch foo to refFilterDontSendRegex, push commits to this branch, and later merge branch foo into master, then the notification email for master will contain a commit email only for the merge commit. If you include foo in refFilterExclusionRegex, then at the time of merge, you will receive one commit email per commit in the branch.

These variables can be multi-valued, like:

[multimailhook]
        refFilterExclusionRegex = ^refs/tags/
        refFilterExclusionRegex = ^refs/heads/master$

You can also provide a whitespace-separated list like:

[multimailhook]
        refFilterExclusionRegex = ^refs/tags/ ^refs/heads/master$

Both examples exclude tags and the master branch, and are equivalent to:

[multimailhook]
        refFilterExclusionRegex = ^refs/tags/|^refs/heads/master$

refFilterInclusionRegex and refFilterExclusionRegex are strictly stronger than refFilterDoSendRegex and refFilterDontSendRegex. In other words, adding a ref to a DoSend/DontSend regex has no effect if it is already excluded by a Exclusion/Inclusion regex.

multimailhook.logFile, multimailhook.errorLogFile, multimailhook.debugLogFile

When set, these variable designate path to files where git-multimail will log some messages. Normal messages and error messages are sent to logFile, and error messages are also sent to errorLogFile. Debug messages and all other messages are sent to debugLogFile. The recommended way is to set only one of these variables, but it is also possible to set several of them (part of the information is then duplicated in several log files, for example errors are duplicated to all log files).

Relative path are relative to the Git repository where the push is done.

multimailhook.verbose

Verbosity level of git-multimail on its standard output. By default, show only error and info messages. If set to true, show also debug messages.

Email filtering aids

All emails include extra headers to enable fine tuned filtering and give information for debugging. All emails include the headers X-Git-Host, X-Git-Repo, X-Git-Refname, and X-Git-Reftype. ReferenceChange emails also include headers X-Git-Oldrev and X-Git-Newrev; Revision emails also include header X-Git-Rev.

Customizing email contents

git-multimail mostly generates emails by expanding templates. The templates can be customized. To avoid the need to edit git_multimail.py directly, the preferred way to change the templates is to write a separate Python script that imports git_multimail.py as a module, then replaces the templates in place. See the provided post-receive script for an example of how this is done.

Customizing git-multimail for your environment

git-multimail is mostly customized via an "environment" that describes the local environment in which Git is running. Two types of environment are built in:

GenericEnvironment

a stand-alone Git repository.

GitoliteEnvironment

a Git repository that is managed by gitolite. For such repositories, the identity of the pusher is read from environment variable $GL_USER, the name of the repository is read from $GL_REPO (if it is not overridden by multimailhook.reponame), and the From: header value is optionally read from gitolite.conf (see multimailhook.from).

By default, git-multimail assumes GitoliteEnvironment if $GL_USER and $GL_REPO are set, and otherwise assumes GenericEnvironment. Alternatively, you can choose one of these two environments explicitly by setting a multimailhook.environment config setting (which can have the value generic or gitolite) or by passing an --environment option to the script.

If you need to customize the script in ways that are not supported by the existing environments, you can define your own environment class class using arbitrary Python code. To do so, you need to import git_multimail.py as a Python module, as demonstrated by the example post-receive script. Then implement your environment class; it should usually inherit from one of the existing Environment classes and possibly one or more of the EnvironmentMixin classes. Then set the environment variable to an instance of your own environment class and pass it to run_as_post_receive_hook().

The standard environment classes, GenericEnvironment and GitoliteEnvironment, are in fact themselves put together out of a number of mixin classes, each of which handles one aspect of the customization. For the finest control over your configuration, you can specify exactly which mixin classes your own environment class should inherit from, and override individual methods (or even add your own mixin classes) to implement entirely new behaviors. If you implement any mixins that might be useful to other people, please consider sharing them with the community!

Getting involved

Please, read CONTRIBUTING.rst for instructions on how to contribute to git-multimail.

Footnotes

---

1. Because of the way information is passed to update hooks, the script's method of determining whether a commit has already been seen does not work when it is used as an update script. In particular, no notification email will be generated for a new commit that is added to multiple references in the same push. A workaround is to use --force-send to force sending the emails.↩

git-multimail's Issues

Configuration sections

It would be nice to allow some configuration keys to have effect only on some refs, like

[mutimailhook]
    var = val
[multimailhook "refs/heads/foo-*"]
    var = otherVal

See #15 for a discussion on the subject.

Implement git_multimail.py --version

AttributeError: 'Push' object has no attribute 'environment'

In recent addition of "quiet" environment variable (commit 64dd424) for suppressing the mailto list, an on existing environment structure is referenced inside Push.send_emails().

~/testing123$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 228 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote: File "hooks/post-receive", line 90, in
remote: git_multimail.run_as_post_receive_hook(environment, mailer)
remote: File "/home/jge/githook_test/hooks/git_multimail.py", line 2410, in run_as_post_receive_hook
remote: push.send_emails(mailer, body_filter=environment.filter_body)
remote: File "/home/jge/githook_test/hooks/git_multimail.py", line 2361, in send_emails
remote: if not self.environment.quiet:
remote: AttributeError: 'Push' object has no attribute 'environment'
To /home/jge/githook_test/

• [new branch] master -> master

gitolite's default "config" option filter is overly conservative, precluding usage of refFilter*Regex options (docs issue)

See #118 for background. We tried to use multimailhook.refFilterInclusionRegex option, and had gitolite barf about suspicious chars in option value (a regex). So, we had to adjust UNSAFE_PATT setting in gitolite.rc (see patch below). Again, maybe worth mentioned that in gitolite.rc (just mention that UNSAFE_PATT may need to be adjusted in that file to give user a direction, and let them research and decide what would be "safe" setting for them).

    gitolite.rc: Override and make more liberal UNSAFE_PATT.

    UNSAFE_PATT appears to be used to validate "config" directives in
    gitolite.conf file (i.e. entries to be added to .git/config of
    gitolite-managed repos). This changes is similar REMOTE_COMMAND_PATT
    override applied previously. Specific cause is the need to specify a
    regex for git-multimail hook.

diff --git a/per-service/git-servers/roles/gitolite/templates/gitolite.rc b/per-service/git-servers/roles/gitolite/templates/gitolite.rc
index 1e74588..d7406e1 100644
--- a/per-service/git-servers/roles/gitolite/templates/gitolite.rc
+++ b/per-service/git-servers/roles/gitolite/templates/gitolite.rc
@@ -190,6 +190,7 @@
 # Allow single quote appear in gitolite commands, useful e.g. with "desc"
 # command.
 $REMOTE_COMMAND_PATT = qr(^[-0-9a-zA-Z._\@/+ :,\%=']*$);
+$UNSAFE_PATT         = qr([`~#\&;<>]);

 # ------------------------------------------------------------------------------
 # per perl rules, this should be the last line in such a file:

Environment reader doesn't always pick up the right $USER

Even after 46ba7f6, when git_multimail.py is invoked with a fixed USER, I still mange to get "artagnon" (my $USER) in some of the test output. What is going on?

Implement git-multimail -c (--config), like git -c var=val

See discussion here: #56 (comment)

Add X-Git-NotificationType header to differentiate between types of notifications

I've noticed that in our group of devs some people love the fact that the diff is emailed, others are only interested in the summary mails and don't want to see the diffs.

Would it be possible to add some kind of mail header that reflects the various types of notifications? People not interested in diffs could then easily filter away those messages:

Following are header suggestions:

X-Git-NotificationType: diff
X-Git-NotificationType: ref_changed_plus_diff
X-Git-NotificationType: ref_changed

ref_changed_plus_diff would cover the new 'fewer emails if single commit' from 18203d0

Is it possible to send notifications only for some branches, not all?

e.g. for some "reasons" we use our tree for release and dev. developers push their contributions in refs/heads/contrib/*, and we have release branches too (master, and stable). I would like to get email notifications for master and stable only.

Make multimailhook.refFilter*Regex more flexible

Reminder of the discussion in #52 : it would be nice to allow whitespace separated list of regex, and multi-valued variables for multimailhook.refFilter*Regex variables.

Invalid encoding in From header

http://permalink.gmane.org/gmane.emacs.diffs/127520 has this From header with an invalid UTF-8 character (it's actually Latin-1 encoded):

From: =?UTF-8?Q?Fabi=E1n_Ezequiel_Gallina?= [email protected]

Note that the Reply-To header has the correct encoding. (You can get the raw article via the NNTP interface.)

'unknown user' on Windows

When used on Windows system, the $USER environment is empty. Instead it should use
'$USERNAME' or something like '$USERNAME@$USERDOMAIN'.

For me replacing

class GenericEnvironmentMixin(Environment):
def get_pusher(self):
return self.osenv.get('USER', 'unknown user')
<<<<
with

class GenericEnvironmentMixin(Environment):
def get_pusher(self):
return self.osenv.get('USERNAME', 'unknown user')

did the trick.

Pathological behavior with lots of tags

Pasted from IRC:

10:37:10 <avar> Trying to do some more hacking on git-multimail
10:37:38 <avar> I tried to roll it out for our main repo at work, but it just hangs on a bunch of git-rev-parse --verify commands
10:37:59 <avar> presumably something to do with the repo having tens of thousands of tags and the behavior trying to detect new commits
10:38:09 <avar> i.e. something like: generate_revision_change_summary
10:38:44 <avar> or something else calling GitObject()
10:38:55 <avar> This was for pushing one commit, ctrl+c'd it after a minute or so.

I haven't debugged this, just noting it here to track it. Seems
git-multimail is really pathological with lots of tags in ways that
the old bash commit script isn't.

The most likely cause is that finding if a commit is "new" is really expensive.

Use git-credential to get SMTP credentials

#85 stores them cleartext in the config file.

Evaluate use as a tool to send patches by mail to mailing lists

At Git Merge 2015 we had a discussion that Setting up Git to send proper email patches is complicated, and that it would be nice to have a tool that sends [PATCH] emails to a configurable email address when commits are pushed to a repository. I wonder whether doing so could be in the scope of git-multimail. Opinions?

In the best case there also would be an easy way to integrate this into GitHub.

Copyright lacks year 2014

It currently just says

Copyright (c) 2012,2013 Michael Haggerty

diffs as mime attachments of type text/x-diff

Hi,

It seems that the mails that multimail sends out are type text/plain.
I think it would be easier to use the mails if they were type multipart, with the log message and header text in a text/plain part, then the diff as an inline text/x-diff attachment. This enables some MUAs to add syntax highlighting for the diff, makes it easier to extract just the diff, etc. Perhaps this could be optional if some people prefer the text/plain style.

Thanks.

refFilter*Regex options "don't work"(tm)

To add to confusing reports I submitted (#118, #119) here's another one. (And I do understand they're confusing, but working in devops, with bunch of issues and projects in works, I can't get to investigate them in details for days/weeks, so figure I'd submit them as our users face them - I hope that provides an interesting perspective too: users just do everything per docs, and it just doesn't work :-D).

So, we use gitolite (as in the issues above), and have to projects:

1. Uses:

    config multimailhook.refFilterInclusionRegex = "linux-linaro-lsk-v\d\.\d+($|-rt|-android)$"

Notification mails get sent out even for branches not matching the regex.

1. Uses:

     config multimailhook.refFilterExclusionRegex = "/trunk$"

Yes, you guessed - notification mails are still sent for branch named "trunk" (it's SVN-imported git repo).

ConfigurationException: No email recipients configured!

I am getting the following stack trace when doing git push origin <branchname>, but subsequently running the same command gives no error, tells me Everything up-to-date. The push is not actually happening as I confirmed from the origin server.

Edit: The push is happening, but I get the stack trace nevertheless.

Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 312 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Traceback (most recent call last):
remote:   File "hooks/post-receive", line 72, in <module>
remote:     environment = git_multimail.GenericEnvironment(config=config)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 2060, in __init__
remote:     super(ProjectdescEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1918, in __init__
remote:     **kw
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1959, in __init__
remote:     **kw
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1926, in __init__
remote:     super(FQDNEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1889, in __init__
remote:     config=config, **kw
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 2031, in __init__
remote:     **kw
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1967, in __init__
remote:     super(PusherDomainEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1728, in __init__
remote:     config=config, **kw
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1719, in __init__
remote:     super(ConfigEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1897, in __init__
remote:     super(MaxlinesEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1854, in __init__
remote:     super(FilterLinesEnvironmentMixin, self).__init__(**kw)
remote:   File "/var/tmp/git-multimail/git_multimail.py", line 1998, in __init__
remote:     raise ConfigurationException('No email recipients configured!')
remote: git_multimail.ConfigurationException: No email recipients configured!
To [email protected]:core-services/core-shell.git
   c3b06f2..bf2999b  master -> master

What am I missing? I am using Git 2.3.1 on OS X and the origin is served by Gitlab.

html colored output

Is it possible to send a html emails with colored diffs - this would greatly improve readability

UnicodeDecodeError if the commiter has non-ascii characters

Version 1.2dev-d64e85e93bd68f2cfd4d5896d125e7d450bdd7a1 (testing under Gerrit).

A UnicodeDecodeError is raised with my commits. If I change my name to Sebastien (s/é/e), it works.

Traceback (most recent call last):
  File "/srv/gerrit/hooks/git_multimail.py", line 3506, in <module>
    main(sys.argv[1:])
  File "/srv/gerrit/hooks/git_multimail.py", line 3498, in main
    run_as_update_hook(environment, mailer, refname, oldrev, newrev, options.force_send)
  File "/srv/gerrit/hooks/git_multimail.py", line 3208, in run_as_update_hook
    push.send_emails(mailer, body_filter=environment.filter_body)
  File "/srv/gerrit/hooks/git_multimail.py", line 3130, in send_emails
    rev.recipients,
  File "/srv/gerrit/hooks/git_multimail.py", line 1838, in send
    self.f.writelines(lines)
  File "/srv/gerrit/hooks/git_multimail.py", line 1463, in generate_combined_email
    for line in self.generate_email(push, body_filter, values):
  File "/srv/gerrit/hooks/git_multimail.py", line 795, in generate_email
    for line in self.generate_email_header(**extra_header_values):
  File "/srv/gerrit/hooks/git_multimail.py", line 1072, in generate_email_header
    self.header_template, **extra_values
  File "/srv/gerrit/hooks/git_multimail.py", line 746, in expand_header_lines
    value = addr_header_encode(value, name)
  File "/srv/gerrit/hooks/git_multimail.py", line 450, in addr_header_encode
    header_name="[email protected]"
  File "/usr/lib/python2.7/email/header.py", line 183, in __init__
    self.append(s, charset, errors)
  File "/usr/lib/python2.7/email/header.py", line 267, in append
    ustr = unicode(s, incodec, errors)

A way to list the refFilter status of each ref

It would be nice to have a command like

$ ./git_multimail.py --list-refs
refs/heads/master all-email-sent
refs/heads/branch excluded
refs/heads/long-lived dont-send
...

so that one could debug the multimailhook.refFilter*Regex variables more easily.

SourceForge merge requests are not triggering git-multimail.

Is there an option to have merge requests trigger git-multimail to send out messages? I have noticed that things are not quite right with SourceForge. For the FlightGear project, here is our commitlogs mailing list archive. An example of a commit which did not produce a message is:

• The original commit in a fork (and its branch)
• The merged merge request.
• The merged commit.

It could be that the problem is with the Allura platform SourceForge uses to manage the merging from forks, but I cannot see how this would not trigger git-multimail in a post-receive hook.

Cheers,
Edward

Support startTLS for SMTP

This should be along the lines of the code proposed in #63: in SMTPmailer,

        elif self.smtpport == 587:
            self.smtp = smtplib.connect(self.smtpserver, self.smtpport)
            self.smtp.ehlo()
            self.smtp.starttls()
            self.smtp.ehlo()

git_multimail broken with python 2.4

git_multimail used to work fine with Python 2.4, but I just upgraded and now get:

[moy@ensiens hooks]$ python2.4 git_multimail.py
File "git_multimail.py", line 2101
class IncrementalDateTime():
^
SyntaxError: invalid syntax

I also have python 2.7 on the same server, so I've just modified the shell bang to use it, but if it's not too hard, it could be nice to restore 2.4 compatibility.

Need a setting to limit the number of mails sent

Debian maintainers often use Git repository to maintain their packages and they like to get commit notices to follow changes in the package. Unfortunately, they also have to merge the main git repository when they update the package to a new upstream version of the software. At that point, git-multimail will possibly generate hundreds of mail for the upstream commits that got merged.

This is very annoying and it would be nice if git-multimail could be told to only send the summary mail when the number of individual commit emails exceeds a pre-defined limit.

Possibility to disable the "refchange" mail when the push contains a single new commit.

I very much like how git-multimail sends individual commits as replies to a top-level "refchange" mail... except when the change is a simple update adding one commit. In that case I have two mails when one would have been more than enough.

Please change this behaviour or at least add an option to disable the "refchange" mail when the change is limited to a ref update adding a single commit. This option would only have an effect when commitlist / refchangelist are not used (or do not differ).

Thank you for your work on git-multimail, it was really needed!

Allow HTML in template messages

Currently, we allow sending HTML with syntax coloring for patches for commit messages. It would be tempting to allow the template message to include actual HTML too (e.g. <a href="...">View the code online</a>), but currently all the content of the message is HTML-escaped, hence this is not possible.

Doc lists incorrect version of minimal supported git

git 1.7.1 does not have "-c" as an option. The doc states "git-multimail is known to work with Git versions back to 1.7.1" which it does not.

Change commit email default format to avoid "Date:" in email body

At least the Zimbra webmail considers that

Date: <Anything>

in the body of a message corresponds to the beginning of a quoted message, and hides this line and everything below by default (including the patch, which is the point of sending a commit email ...). Changing the default format to something like

AuthorDate: ...

(Or Authored on: ...)

would work around this behavior of Zimbra. May also benefit some other users.

Improve sorting in e-mail clients

First of all, great project. I've been using it for submin (github.com/mjholtkamp/submin, it's a web admin frontend for git and subversion) and I've been very happy with it!

I've noticed that if you push a large set of commits, most e-mail clients (I've tested Thunderbird and Mail.app) will not sort the mails sent by git-multimail correctly. This is probably due to their sorting by date. (They are correctly grouped together in 'threads' or 'conversations').

Reading the commits/changesets in a-chronological order is confusing, especially if the 'summary' email is not the first e-mail in the 'conversation' (e.g. in Mail.app).

Chaining references (In-Reply-To points to one changeset before, instead of to the summary) would probably fix some e-mail clients, but not all (otherwise Mail.app would show the summary e-mail as the first one in the 'conversation').

How about forcing the sort order by artificially changing the sent date slightly? Since the resolution of the date/time is in seconds, we could increase each sequential message by 1 second (faking a 'delay' in when they were sent).

Possible problems: e-mails are sent in the future.

Is this a problem? Even if you send 59 changesets (+ 1 summary), the difference with the real sending time is only one minute. It's not correct of course, but I think a couple of seconds of difference is a small price to pay for readability.

What do you think?

Test non-ascii characters in branch names

This may cause issues both in "normal" usage and with gerrit which pass branch names as command-line parameters.

gitolite integration doc should mention issue with empty-valued options

We're using git-multimail with gitolite and experiencing few problems. As I'm trying to investigate them further, I'd like to start recording them (as again, there're few (>1) issues). Worst case, it's kind of user error on our side. But even then, it may be worth to mention such issues on git-multmail docs.

So, git-multimail depends on being able to set some options to empty string (e.g. multimailhook.mailingList, and other multimailhook.*List options). We used obvious gitolite.conf syntax:

config multimailhook.commitList = ""

and only later spotted that with the syntax above, gitolite simply doesn't put multimailhook.commitList options to a particular repo's .git/config at all, which of course causes it behave rather different from the expectation.

gitolite configuration parsing support not compatible with python 2.6

The following construct (at line 2908 as of 7329408) requires python 2.7 or 3.1 to work, and doesn't work under python 2.6:

re_template = r'^\s*#\s*{}\s*$'

The following does work (replace {} with {0}):

re_template = r'^\s*#\s*{0}\s*$'

Pass '-oi' to sendmail by default

The default mail submission method is sendmail. sendmail defaults to quitting on a line containing only a ".". The -oi flag can be used to suppress that behaviour (it's the "IgnoreDots" sendmail option).

I would suggest to add -oi to the default flags in sendmail mode. I'm not aware of any portability issues with that option.

gitolite.rst could use some editing for clarity

Reading thru https://github.com/git-multimail/git-multimail/blob/master/doc/gitolite.rst , it might use some editing for clarity. Specific, first line/paragraph is a bit confusing:

git-multimail supports gitolite natively. Setting up git-multimail on a gitolite 3 installation can be done like this:

"supports natively", what does that mean? Perhaps saying "has special support for gitolite (see "custom environment" in README)". Second sentence, ending with colon, seems like stray at all, given the following paragraph.

Possibility to filter log messages prior to ouput

Hello,

For my use case, I'd quite like to include two pieces of extra information - a link to the gitweb/cgit interface (which can be useful at times) but more importantly to convert any bug references in commit logs to clickable links.

e.g. I may have fdo#123 or gh#123 or simply just #123 in the log message and I'd like to include full links appended to the bottom of the message, but before the diff.

I figured that simply providing a config option for a filter script that is run after the git log, prior to returning the data to for injection into the email would allow this.

The script would read everything from the start up to the line with three -'s, it would buffer everything up to this point, do some regexp magic and then inject the appropriate extra links appropriately. I figure the filter script is the easiest way to do this without writing specific functionality into multimail itself with complex buglink regexp configs etc (keeping in mind there may be more than one!)

If I were do make such a change would you accept it upstream?

Rendering of some (unorthodox) commit summaries is sub-ideal

We use git-multimail on mirror of https://github.com/gcc-mirror/gcc . Commit message there don't follow git guidelines, and are heritage of ChangeLog file format. There're commits like gcc-mirror/gcc@75c3f23 which lead to git-multimail messages like:

      from  75c3f23     * genmatch.c (fprintf_indent): New function.    (operand::gen_transform): Add indent parameter.     (expr::gen_transform, c_expr::gen_transform,    capture::gen_transform): Ditto and use fprintf_indent.  (dt_node::gen, dt_node::gen_kids, dt_node::gen_kids_1): Ditto.  (dt_operand::gen, dt_operand::gen_predicate,    dt_operand::gen_match_op, dt_operand::gen_gimple_expr,  dt_operand::gen_generic_expr, dt_simplify::gen): Ditto.     (decision_tree::gen_gimple): Adjust calls and inde [...]
       new  853a01d   2015-07-09  Vladimir Makarov  <[email protected]>

It would be to have an option to force usage of single first line as summary (vs git convention that summary is separate from details with a blank line, with an extreme case of summary being multi-line).

Possibility to use committer as "From" in generated mails

We have a limited set of committers and we like to see who commited directly in the "From" field. Please make it possible to use that identity in the From field ideally with a simple setting, otherwise at least with wrapper script.

Right now, it's not possible to override get_fromaddr() of the Environment because it doesn't get the details of the commit or from the changes.

How to get announce email only?

Hi, if I only set multimailhook.announceList to some email addresses, but left other list-related options unset, always got

remote: The list of recipients for refchangelist is not configured.
remote: Please set one of the following:
remote: "multimailhook.refchangelist"
remote: "multimailhook.mailinglist"

in the case, no email got sent.

but I don't want every commit email being sent, only important tag/release notification.
Did I config anything wrong? Thanks.

License unknown

Hello,

I've seen your project and it looks like something I want to include in a project (Submin) that uses a BSD-style License. It won't be fully integrated, because I would like to contribute my changes so other projects can use it too.

However, I could not find any LICENSE information in your project. Would you be willing to add a LICENSE file (preferably BSD/MIT-style, so it's compatible and we can include it)?

Submin is still in Subversion and I would like to convert Submin to git, but one of the things that I would be missing is a commit-email script, so I'm still a bit hesitant to do so. Using your script would help me achieve that goal more easily :-)

Thanks in advance,
Michiel

Emails not delivered (gitolite setup)

Can anyone help me with this issue?
http://stackoverflow.com/questions/24465137/how-to-enable-git-multimail-hook-in-gitolite

I'm not sure where to look for any error messages.

test strictutf8 better (especially Python3)

The code dealing with strictutf8 is not activated at all in Python 3 so it has to be broken. But the testsuite passes ...

Generates invalid Reply-To header in some situations

FWIW I have setup git-multimail on git.debian.org and many people are now using it. I just got a report of some invalid mail generated by git-multimail. When a user pushed this commit: http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commit;h=3bbaa34ddf253dfdd9aee041e8d571a97e73584e

He got back a bounce saying "550 Message headers fail syntax check" (this is exim giving back this answer) and the only thing that looks weird in the mail is the Reply-to header:

Return-path: <[email protected]>
Received: from nthykier by vasks.debian.org with local (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1V6dV3-0005q4-Qc; Tue, 06 Aug 2013 09:24:17 +0000
To: [email protected]
Subject: [lintian] 02/03: Add generic infrastructure for checking
 common-licenses
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Reply-To: =?utf-8?q?_Bastien_ROUCARI=C3=88S_=3Croucaries=2Ebastien=40gmai?=
 =?utf-8?b?bC5jb20+?=
In-Reply-To: <[email protected]>
References: <[email protected]>
X-Git-Repo: lintian
X-Git-Refname: refs/heads/master
X-Git-Reftype: branch
X-Git-Rev: 3bbaa34ddf253dfdd9aee041e8d571a97e73584e
Auto-Submitted: auto-generated
Message-Id: <[email protected]>
From: Niels Thykier <[email protected]>
Date: Tue, 06 Aug 2013 09:24:17 +0000

Any idea what's going wrong here?

Note that git-format-patch outputs “From: =?UTF-8?q?Bastien=20ROUCARI=C3=88S?= [email protected]” so it definitely encodes the identity/email more wisely.

Testing docs could provide more details

I spent some time figuring out got I can get to the actual email contents for a failed test - until finally figured out that I should comment out "cleanup" "test". Docs could mention that, or even better, don't delete test repo in case of failures (or if it's too hard, don't delete test repo at the end of test at all).

Also, what about providing more "unit" tests? For example, for #118, what I really need to test is that for both commitList='' and commitList=none result of Config.get_recipients() is the same.

Whereas what's available now are integration tests, which are, well, PITA to work with, as there're many restrictions, etc. For example, test repo has announceList set, add using command-line option -c just adds to it, so I cannot really test "empty string or single 'none'" behavior without tricks, which you (and whoever novice will look into it later) would certainly find dirty tricks. End result is that I can't really contribute a testcase with the changes for #118.

Possibility to use SMTP authentication

I'd like to use a login/password to access to my SMTP server.

Allow retrieving configuration from the repository itself

Git does not allow git add .git/config (partly for security reason), but it could make sense to have a .git-multimail file tracked within the repository, that git-multimail would read, to allow anyone with write access to change the configuration of git-multimail.

Typical use-case: a server where only the sysadmin has shell access, but where users would want to configure the list of recipients without having to ask the sysadmin.

Obvious drawback: this pollutes the history with configuration changes.

Warning: we should be careful with security and check that no variable read from this file allow executing arbitrary command. It should probably be disabled by default (but can be activated from /etc/gitconfig as needed).

Omit certain paths from emails

Hello,

I would like it if I could configure certain paths in the git repository that would not be sent as diffs in email. In particular, I'm wanting to keep certain secret material (keys, passwords) in a specific directory in a git repository, but when I push to the repository, I don't want the normal commit diff email to be sent out because it will include copies of those keys. I do want the commit diffs for the rest of the repository, as those are quite useful to see, but just omit certain paths (like .gitignore).

Another option would be to add openpgp encryption to the mails, but that sounds a lot harder :)

Allow git-multimail to run as a webhook for GitHub

GitHub already has a builtin hook to send emails, but it is not very convenient and certainly not as flexible as git-multimail. It would be nice to allow a git-multimail service to be hosted outside GitHub, and have it send emails when it receives an event from a webhook.

Once this is done, it would be nice to setup such a service for git-multimail itself, to make it "self-hosted".

Note that this is not as straightforward as it seems to be, since git-multimail would run on a machine that is not where the repository is hosted. The simplest way to deal with this would be to keep a mirror of the repository on the machine running git-multimail.py: the hook would trigger a fetch, and then run git-multimail more or less normally on the mirrored repository. One difficulty is that running git-multimail after the check would break the "new commits detection".

make post-receive file less misleading.

As noted my @mhagger on #59, we should rename it to post-receive.example or find another way to avoid having people use it when they really wanted git_multimail.py.

Individual email per recepient

Hello!

At the moment all email addresses listed in multimailhook.mailingList are collected in "To: " header. Is there a way to split it and send one email to each recepient for they not to see all the other recepients in "To: " field?

If there is no built-in way could you please suggest a place in the code where it can be done?

Alexander