Package: git-multimail
git-multimail is a tool for sending notification emails on pushes to a
Git repository.  It includes a Python module calledgit_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, readhttps://github.com/git-multimail/git-multimail/blob/master/CONTRIBUTING.rstfor more information.By default, for each push received by the repository, git-multimail: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.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-rc2By 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. Seemultimailhook.refFilter(Inclusion|Exclusion|DoSend|DontSend)Regexbelow 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.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.RequirementsPython 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).Thegitcommand 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. Seehttps://github.com/git-multimail/git-multimail/blob/master/CONTRIBUTING.rstto improve the situation.Invocationgit_multimail.pyis designed to be used as apost-receivehook 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.pycan also work as
anupdatehook, 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[1].Alternatively,git_multimail.pycan 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) tochange how the user who did the push is determinedread users’ email addresses from an LDAP server or from a databasedecide 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.  Thepost-receivescript in this directory demonstrates how
to usegit_multimail.pyas a Python module.  (If you make interesting
changes of this type, please consider sharing them with the
community.)Troubleshooting/FAQPlease readhttps://github.com/git-multimail/git-multimail/blob/master/doc/troubleshooting.rstfor frequently asked
questions and common issues with git-multimail.ConfigurationBy default, git-multimail mostly takes its configuration from the
followinggit configsettings:multimailhook.environmentThis describes the general environment of the repository. In most
cases, you do not need to specify a value for this variable:git-multimailwill autodetect which environment to use.
Currently supported values:genericthe username of the pusher is read from $USER or $USERNAME and
the repository name is derived from the repository’s path.gitoliteEnvironment to use whengit-multimailis ran as agitolitehook.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, readhttps://github.com/git-multimail/git-multimail/blob/master/doc/gitolite.rststashEnvironment to use whengit-multimailis 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-userand--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.gerritEnvironment to use whengit-multimailis ran as aref-updatedGerrit 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--submitterargument if that command line option is passed,
otherwise ‘Gerrit’ is used. The repository name is taken from
the--projectoption on the command line, which must be passed.For more information about gerrit and git-multimail, readhttps://github.com/git-multimail/git-multimail/blob/master/doc/gerrit.rstIf 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--environmentoption. If it is not specified on the
command line or bymultimailhook.environment, the value is
guessed as follows:If stash-specific (respectively gerrit-specific) command flags
are present on the command-line, thenstash(respectivelygerrit) is used.If the environment variables $GL_USER and $GL_REPO are set, thengitoliteis used.If none of the above apply, thengenericis used.multimailhook.repoNameA 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.mailingListThe 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.refchangeListThe 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.announceListThe 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.commitListThe 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.announceShortlogIf 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.commitEmailFormatThe 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 ofgit logwith-p. When usingmultimailhook.commitLogOptsto specify a--formatforgit 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. Seemultimailhook.htmlInIntroto change this behavior.multimailhook.commitBrowseURLUsed to generate a link to an online repository browser in commit
emails. This variable must be a string. Format directives like%(<variable>)swill be expanded the same way as template
strings. In particular,%(id)swill be replaced by the full
Git commit identifier (40-chars hexadecimal).If the string does not contain any format directive, then%(id)swill be automatically added to the string. If you don’t
want%(id)sto be automatically added, use the empty format
directive%()sanywhere in the string.For example, a suitable value for the git-multimail project itself
would behttps://github.com/git-multimail/git-multimail/commit/%(id)s.multimailhook.htmlInIntro, multimailhook.htmlInFooterWhen generating an HTML message, git-multimail escapes any HTML
sequence by default. This means that if a template contains HTML
like<ahref="foo">link</a>, the reader will see the HTML
source code and not a proper link.Setmultimailhook.htmlInIntroto true to allow writing HTML
formatting in introduction templates. Similarly, setmultimailhook.htmlInFooterfor 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.Readhttps://github.com/git-multimail/git-multimail/blob/master/doc/customizing-emails.rstfor more details and
examples.multimailhook.refchangeShowGraphIf 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 runninggit log--graphwith the options
specified in graphOpts.  The default is false.multimailhook.refchangeShowLogIf 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 runninggit logwith the options specified in multimailhook.logOpts.
Default is false.multimailhook.mailerThis option changes the way emails are sent.  Accepted values are:sendmail (the default): use the command/usr/sbin/sendmailor/usr/lib/sendmail(or sendmailCommand, if configured).  This
mode can be further customized via the following options:multimailhook.sendmailCommandThe command used by mailersendmailto 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.envelopeSenderIf 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.smtpServerThe 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.smtpPassServer 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.envelopeSenderThe sender address to be passed to the SMTP server.  If
unset, then the value of multimailhook.from is used.multimailhook.smtpServerTimeoutTimeout in seconds. Default is 10.multimailhook.smtpEncryptionSet the security type. Allowed values:none,ssl,tls(starttls).
Default isnone.multimailhook.smtpCACertsSet the path to a list of trusted CA certificate to verify the
server certificate, only supported whensmtpEncryptionistls. 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.crtfor 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-certificatesand used the updated/etc/ssl/certs/ca-certificates.crt. Or
directly use your/path/to/mail.example.net.crt. Default is
unset.multimailhook.smtpServerDebugLevelInteger number. Set to greater than 0 to activate debugging.multimailhook.from, multimailhook.fromCommit, multimailhook.fromRefchangeIf set, use this value in the From: field of generated emails.fromCommitis used for commit emails,fromRefchangeis
used for refchange emails, andfromis used as fall-back in
all cases.The value for these variables can be either:An email address, which will be used directly.The valuepusher, in which case the pusher’s address (if
available) will be used.The valueauthor(meaningful only forfromCommit), 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:(gitolite environment only)
1.a) Ifmultimailhook.MailaddressMapis set, and is a path
to an existing file (if relative, it is considered relative to
the place wheregitolite.confis located), then this file
should contain lines like:username Firstname Lastname <email@example.com>git-multimail will then look for a line where$GL_USERmatches theusernamepart, and use the rest of the line for
theFrom:header.1.b) Parse gitolite.conf, looking for a block of comments that
looks like this:# BEGIN USER EMAILS
# username Firstname Lastname <email@example.com>
# END USER EMAILSIf 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.If the user.email configuration setting is set, use its value
(and the value of user.name, if set).Use the value of multimailhook.envelopeSender.multimailhook.MailaddressMap(gitolite environment only)
File to look for aFrom:address based on the user doing the
push. Defaults to unset. Seemultimailhook.fromfor details.multimailhook.administratorThe 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.emailPrefixAll 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)sfor the short name of
the repository.multimailhook.emailMaxLinesThe 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.emailMaxLineLengthThe 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.subjectMaxLengthThe maximum length of the subject line (i.e. theonelinefield
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 usemultimailhook.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.maxCommitEmailsThe 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.excludeMergeRevisionsWhen sending out revision emails, do not consider merge commits (the
functional equivalent ofrev-list –no-merges).
The default isfalse(send merge commit emails).multimailhook.emailStrictUTF8If this boolean option is set totrue, 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 istrue.This option is ineffective with Python 3, where non-UTF-8
characters are unconditionally replaced.multimailhook.diffOptsOptions passed togitdiff-treewhen 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; seemultimailhook.logOptsfor
details.multimailhook.graphOptsOptions passed togit log--graphwhen 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.logOptsOptions passed togit logto 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.commitLogOptsOptions passed togit logto 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.dateSubstituteString to use as a substitute forDate:in the output ofgit logwhile 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 toCommitDate:. Set to an empty string ornoneto deactivate
the behavior.multimailhook.emailDomainDomain 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.replyToRefchangeAddresses 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 shortcutspusherandauthorare allowed with the same semantics as formultimailhook.from. In addition, the valuenonecan be
used to omit theReply-To:field.The default ispusherfor refchange emails, andauthorfor
commit emails.multimailhook.quietDo not output the list of email recipients from the hookmultimailhook.stdoutFor debugging, send emails to stdout rather than to the
mailer.  Equivalent to the –stdout command line optionmultimailhook.scanCommitForCcIf this option is set to true, than recipients from lines in commit body
that starts withCC:will be added to CC list.
Default: falsemultimailhook.combineWhenSingleCommitIf 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: truemultimailhook.refFilterInclusionRegex, multimailhook.refFilterExclusionRegex, multimailhook.refFilterDoSendRegex, multimailhook.refFilterDontSendRegexWarning: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 arefFilterInclusionRegexis
specified, emails will only be sent for refs which match this
regex.  If arefFilterExclusionRegexregex 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, setrefFilterExclusionRegexto^refs/tags/(note the leading^but no trailing$). If
you setrefFilterExclusionRegextomaster, then any ref
containingmasterwill be excluded (themasterbranch, but
alsorefs/tags/masterorrefs/heads/foo-master-bar).refFilterDoSendRegexandrefFilterDontSendRegexare
analogous torefFilterInclusionRegexandrefFilterExclusionRegexwith one difference: withrefFilterDoSendRegexandrefFilterDontSendRegex, commits
introduced by one excluded ref will not be considered as new when
they reach an included ref. Typically, if you add a branchfootorefFilterDontSendRegex, push commits to this branch, and
later merge branchfoointomaster, then the notification
email formasterwill contain a commit email only for the
merge commit. If you includefooinrefFilterExclusionRegex, 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$refFilterInclusionRegexandrefFilterExclusionRegexare
strictly stronger thanrefFilterDoSendRegexandrefFilterDontSendRegex. 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.debugLogFileWhen set, these variable designate path to files where
git-multimail will log some messages. Normal messages and error
messages are sent tologFile, and error messages are also sent
toerrorLogFile. Debug messages and all other messages are
sent todebugLogFile. 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.verboseVerbosity 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 aidsAll emails include extra headers to enable fine tuned filtering and
give information for debugging.  All emails include the headersX-Git-Host,X-Git-Repo,X-Git-Refname, andX-Git-Reftype.
ReferenceChange emails also include headersX-Git-OldrevandX-Git-Newrev;
Revision emails also include headerX-Git-Rev.Customizing email contentsgit-multimail mostly generates emails by expanding templates.  The
templates can be customized.  To avoid the need to editgit_multimail.pydirectly, the preferred way to change the templates
is to write a separate Python script that importsgit_multimail.pyas
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 environmentgit-multimail is mostly customized via an “environment” that describes
the local environment in which Git is running.  Two types of
environment are built in:GenericEnvironmenta stand-alone Git repository.GitoliteEnvironmenta Git repository that is managed bygitolite.  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 amultimailhook.environmentconfig setting (which can
have the valuegenericorgitolite) 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 importgit_multimail.pyas 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 theenvironmentvariable to an instance of your own environment class
and pass it torun_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 involvedPlease, readhttps://github.com/git-multimail/git-multimail/blob/master/CONTRIBUTING.rstfor 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 anupdatescript.
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.