{ "info": { "author": "Matthieu Moy", "author_email": "git@matthieu-moy.fr", "bugtrack_url": null, "classifiers": [ "Development Status :: 5 - Production/Stable", "Environment :: No Input/Output (Daemon)", "Intended Audience :: Developers", "Intended Audience :: System Administrators", "License :: OSI Approved :: GNU General Public License v2 (GPLv2)", "Operating System :: OS Independent", "Programming Language :: Python :: 2", "Programming Language :: Python :: 3", "Topic :: Communications :: Email", "Topic :: Software Development :: Version Control" ], "description": "git-multimail version 1.5.0\n===========================\n\n.. image:: https://travis-ci.org/git-multimail/git-multimail.svg?branch=master\n :target: https://travis-ci.org/git-multimail/git-multimail\n\ngit-multimail is a tool for sending notification emails on pushes to a\nGit repository. It includes a Python module called ``git_multimail.py``,\nwhich can either be used as a hook script directly or can be imported\nas a Python module into another script.\n\ngit-multimail is derived from the Git project's old\ncontrib/hooks/post-receive-email, and is mostly compatible with that\nscript. See README.migrate-from-post-receive-email for details about\nthe differences and for how to migrate from post-receive-email to\ngit-multimail.\n\ngit-multimail, like the rest of the Git project, is licensed under\nGPLv2 (see the COPYING file for details).\n\nPlease note: although, as a convenience, git-multimail may be\ndistributed along with the main Git project, development of\ngit-multimail takes place in its own, separate project. Please, read\n``__ for more information.\n\n\nBy default, for each push received by the repository, git-multimail:\n\n1. Outputs one email summarizing each reference that was changed.\n These \"reference change\" (called \"refchange\" below) emails describe\n the nature of the change (e.g., was the reference created, deleted,\n fast-forwarded, etc.) and include a one-line summary of each commit\n that was added to the reference.\n\n2. Outputs one email for each new commit that was introduced by the\n reference change. These \"commit\" emails include a list of the\n files changed by the commit, followed by the diffs of files\n modified by the commit. The commit emails are threaded to the\n corresponding reference change email via \"In-Reply-To\". This style\n (similar to the \"git format-patch\" style used on the Git mailing\n list) makes it easy to scan through the emails, jump to patches\n that need further attention, and write comments about specific\n commits. Commits are handled in reverse topological order (i.e.,\n parents shown before children). For example::\n\n [git] branch master updated\n + [git] 01/08: doc: fix xref link from api docs to manual pages\n + [git] 02/08: api-credentials.txt: show the big picture first\n + [git] 03/08: api-credentials.txt: mention credential.helper explicitly\n + [git] 04/08: api-credentials.txt: add \"see also\" section\n + [git] 05/08: t3510 (cherry-pick-sequence): add missing '&&'\n + [git] 06/08: Merge branch 'rr/maint-t3510-cascade-fix'\n + [git] 07/08: Merge branch 'mm/api-credentials-doc'\n + [git] 08/08: Git 1.7.11-rc2\n\n By default, each commit appears in exactly one commit email, the\n first time that it is pushed to the repository. If a commit is later\n merged into another branch, then a one-line summary of the commit\n is included in the reference change email (as usual), but no\n additional commit email is generated. See\n `multimailhook.refFilter(Inclusion|Exclusion|DoSend|DontSend)Regex`\n below to configure which branches and tags are watched by the hook.\n\n By default, reference change emails have their \"Reply-To\" field set\n to the person who pushed the change, and commit emails have their\n \"Reply-To\" field set to the author of the commit.\n\n3. Output one \"announce\" mail for each new annotated tag, including\n information about the tag and optionally a shortlog describing the\n changes since the previous tag. Such emails might be useful if you\n use annotated tags to mark releases of your project.\n\n\nRequirements\n------------\n\n* Python 2.x, version 2.4 or later. No non-standard Python modules\n are required. git-multimail has preliminary support for Python 3\n (but it has been better tested with Python 2).\n\n* The ``git`` command must be in your PATH. git-multimail is known to\n work with Git versions back to 1.7.1. (Earlier versions have not\n been tested; if you do so, please report your results.)\n\n* To send emails using the default configuration, a standard sendmail\n program must be located at '/usr/sbin/sendmail' or\n '/usr/lib/sendmail' and must be configured correctly to send emails.\n If this is not the case, set multimailhook.sendmailCommand, or see\n the multimailhook.mailer configuration variable below for how to\n configure git-multimail to send emails via an SMTP server.\n\n* git-multimail is currently tested only on Linux. It may or may not\n work on other platforms such as Windows and Mac OS. See\n ``__ to improve the situation.\n\n\nInvocation\n----------\n\n``git_multimail.py`` is designed to be used as a ``post-receive`` hook in a\nGit repository (see githooks(5)). Link or copy it to\n$GIT_DIR/hooks/post-receive within the repository for which email\nnotifications are desired. Usually it should be installed on the\ncentral repository for a project, to which all commits are eventually\npushed.\n\nFor use on pre-v1.5.1 Git servers, ``git_multimail.py`` can also work as\nan ``update`` hook, taking its arguments on the command line. To use\nthis script in this manner, link or copy it to $GIT_DIR/hooks/update.\nPlease note that the script is not completely reliable in this mode\n[1]_.\n\nAlternatively, ``git_multimail.py`` can be imported as a Python module\ninto your own Python post-receive script. This method is a bit more\nwork, but allows the behavior of the hook to be customized using\narbitrary Python code. For example, you can use a custom environment\n(perhaps inheriting from GenericEnvironment or GitoliteEnvironment) to\n\n* change how the user who did the push is determined\n\n* read users' email addresses from an LDAP server or from a database\n\n* decide which users should be notified about which commits based on\n the contents of the commits (e.g., for users who want to be notified\n only about changes affecting particular files or subdirectories)\n\nOr you can change how emails are sent by writing your own Mailer\nclass. The ``post-receive`` script in this directory demonstrates how\nto use ``git_multimail.py`` as a Python module. (If you make interesting\nchanges of this type, please consider sharing them with the\ncommunity.)\n\n\nTroubleshooting/FAQ\n-------------------\n\nPlease read ``__ for frequently asked\nquestions and common issues with git-multimail.\n\n\nConfiguration\n-------------\n\nBy default, git-multimail mostly takes its configuration from the\nfollowing ``git config`` settings:\n\nmultimailhook.environment\n This describes the general environment of the repository. In most\n cases, you do not need to specify a value for this variable:\n `git-multimail` will autodetect which environment to use.\n Currently supported values:\n\n generic\n the username of the pusher is read from $USER or $USERNAME and\n the repository name is derived from the repository's path.\n\n gitolite\n Environment to use when ``git-multimail`` is ran as a gitolite_\n hook.\n\n The username of the pusher is read from $GL_USER, the repository\n name is read from $GL_REPO, and the From: header value is\n optionally read from gitolite.conf (see multimailhook.from).\n\n For more information about gitolite and git-multimail, read\n ``__\n\n stash\n Environment to use when ``git-multimail`` is ran as an Atlassian\n BitBucket Server (formerly known as Atlassian Stash) hook.\n\n **Warning:** this mode was provided by a third-party contributor\n and never tested by the git-multimail maintainers. It is\n provided as-is and may or may not work for you.\n\n This value is automatically assumed when the stash-specific\n flags (``--stash-user`` and ``--stash-repo``) are specified on\n the command line. When this environment is active, the username\n and repo come from these two command line flags, which must be\n specified.\n\n gerrit\n Environment to use when ``git-multimail`` is ran as a\n ``ref-updated`` Gerrit hook.\n\n This value is used when the gerrit-specific command line flags\n (``--oldrev``, ``--newrev``, ``--refname``, ``--project``) for\n gerrit's ref-updated hook are present. When this environment is\n active, the username of the pusher is taken from the\n ``--submitter`` argument if that command line option is passed,\n otherwise 'Gerrit' is used. The repository name is taken from\n the ``--project`` option on the command line, which must be passed.\n\n For more information about gerrit and git-multimail, read\n ``__\n\n If none of these environments is suitable for your setup, then you\n can implement a Python class that inherits from Environment and\n instantiate it via a script that looks like the example\n post-receive script.\n\n The environment value can be specified on the command line using\n the ``--environment`` option. If it is not specified on the\n command line or by ``multimailhook.environment``, the value is\n guessed as follows:\n\n * If stash-specific (respectively gerrit-specific) command flags\n are present on the command-line, then ``stash`` (respectively\n ``gerrit``) is used.\n\n * If the environment variables $GL_USER and $GL_REPO are set, then\n ``gitolite`` is used.\n\n * If none of the above apply, then ``generic`` is used.\n\nmultimailhook.repoName\n A short name of this Git repository, to be used in various places\n in the notification email text. The default is to use $GL_REPO\n for gitolite repositories, or otherwise to derive this value from\n the repository path name.\n\nmultimailhook.mailingList\n The list of email addresses to which notification emails should be\n sent, as RFC 2822 email addresses separated by commas. This\n configuration option can be multivalued. Leave it unset or set it\n to the empty string to not send emails by default. The next few\n settings can be used to configure specific address lists for\n specific types of notification email.\n\nmultimailhook.refchangeList\n The list of email addresses to which summary emails about\n reference changes should be sent, as RFC 2822 email addresses\n separated by commas. This configuration option can be\n multivalued. The default is the value in\n multimailhook.mailingList. Set this value to \"none\" (or the empty\n string) to prevent reference change emails from being sent even if\n multimailhook.mailingList is set.\n\nmultimailhook.announceList\n The list of email addresses to which emails about new annotated\n tags should be sent, as RFC 2822 email addresses separated by\n commas. This configuration option can be multivalued. The\n default is the value in multimailhook.refchangeList or\n multimailhook.mailingList. Set this value to \"none\" (or the empty\n string) to prevent annotated tag announcement emails from being sent\n even if one of the other values is set.\n\nmultimailhook.commitList\n The list of email addresses to which emails about individual new\n commits should be sent, as RFC 2822 email addresses separated by\n commas. This configuration option can be multivalued. The\n default is the value in multimailhook.mailingList. Set this value\n to \"none\" (or the empty string) to prevent notification emails about\n individual commits from being sent even if\n multimailhook.mailingList is set.\n\nmultimailhook.announceShortlog\n If this option is set to true, then emails about changes to\n annotated tags include a shortlog of changes since the previous\n tag. This can be useful if the annotated tags represent releases;\n then the shortlog will be a kind of rough summary of what has\n happened since the last release. But if your tagging policy is\n not so straightforward, then the shortlog might be confusing\n rather than useful. Default is false.\n\nmultimailhook.commitEmailFormat\n The format of email messages for the individual commits, can be \"text\" or\n \"html\". In the latter case, the emails will include diffs using colorized\n HTML instead of plain text used by default. Note that this currently the\n ref change emails are always sent in plain text.\n\n Note that when using \"html\", the formatting is done by parsing the\n output of ``git log`` with ``-p``. When using\n ``multimailhook.commitLogOpts`` to specify a ``--format`` for\n ``git log``, one may get false positive (e.g. lines in the body of\n the message starting with ``+++`` or ``---`` colored in red or\n green).\n\n By default, all the message is HTML-escaped. See\n ``multimailhook.htmlInIntro`` to change this behavior.\n\nmultimailhook.commitBrowseURL\n Used to generate a link to an online repository browser in commit\n emails. This variable must be a string. Format directives like\n ``%()s`` will be expanded the same way as template\n strings. In particular, ``%(id)s`` will be replaced by the full\n Git commit identifier (40-chars hexadecimal).\n\n If the string does not contain any format directive, then\n ``%(id)s`` will be automatically added to the string. If you don't\n want ``%(id)s`` to be automatically added, use the empty format\n directive ``%()s`` anywhere in the string.\n\n For example, a suitable value for the git-multimail project itself\n would be\n ``https://github.com/git-multimail/git-multimail/commit/%(id)s``.\n\nmultimailhook.htmlInIntro, multimailhook.htmlInFooter\n When generating an HTML message, git-multimail escapes any HTML\n sequence by default. This means that if a template contains HTML\n like ``link``, the reader will see the HTML\n source code and not a proper link.\n\n Set ``multimailhook.htmlInIntro`` to true to allow writing HTML\n formatting in introduction templates. Similarly, set\n ``multimailhook.htmlInFooter`` for HTML in the footer.\n\n Variables expanded in the template are still escaped. For example,\n if a repository's path contains a ``<``, it will be rendered as\n such in the message.\n\n Read ``__ for more details and\n examples.\n\nmultimailhook.refchangeShowGraph\n If this option is set to true, then summary emails about reference\n changes will additionally include:\n\n * a graph of the added commits (if any)\n\n * a graph of the discarded commits (if any)\n\n The log is generated by running ``git log --graph`` with the options\n specified in graphOpts. The default is false.\n\nmultimailhook.refchangeShowLog\n If this option is set to true, then summary emails about reference\n changes will include a detailed log of the added commits in\n addition to the one line summary. The log is generated by running\n ``git log`` with the options specified in multimailhook.logOpts.\n Default is false.\n\nmultimailhook.mailer\n This option changes the way emails are sent. Accepted values are:\n\n * **sendmail (the default)**: use the command ``/usr/sbin/sendmail`` or\n ``/usr/lib/sendmail`` (or sendmailCommand, if configured). This\n mode can be further customized via the following options:\n\n multimailhook.sendmailCommand\n The command used by mailer ``sendmail`` to send emails. Shell\n quoting is allowed in the value of this setting, but remember that\n Git requires double-quotes to be escaped; e.g.::\n\n git config multimailhook.sendmailcommand '/usr/sbin/sendmail -oi -t -F \\\"Git Repo\\\"'\n\n Default is '/usr/sbin/sendmail -oi -t' or\n '/usr/lib/sendmail -oi -t' (depending on which file is\n present and executable).\n\n multimailhook.envelopeSender\n If set then pass this value to sendmail via the -f option to set\n the envelope sender address.\n\n * **smtp**: use Python's smtplib. This is useful when the sendmail\n command is not available on the system. This mode can be\n further customized via the following options:\n\n multimailhook.smtpServer\n The name of the SMTP server to connect to. The value can\n also include a colon and a port number; e.g.,\n ``mail.example.com:25``. Default is 'localhost' using port 25.\n\n multimailhook.smtpUser, multimailhook.smtpPass\n Server username and password. Required if smtpEncryption is 'ssl'.\n Note that the username and password currently need to be\n set cleartext in the configuration file, which is not\n recommended. If you need to use this option, be sure your\n configuration file is read-only.\n\n multimailhook.envelopeSender\n The sender address to be passed to the SMTP server. If\n unset, then the value of multimailhook.from is used.\n\n multimailhook.smtpServerTimeout\n Timeout in seconds. Default is 10.\n\n multimailhook.smtpEncryption\n Set the security type. Allowed values: ``none``, ``ssl``, ``tls`` (starttls).\n Default is ``none``.\n\n multimailhook.smtpCACerts\n Set the path to a list of trusted CA certificate to verify the\n server certificate, only supported when ``smtpEncryption`` is\n ``tls``. If unset or empty, the server certificate is not\n verified. If it targets a file containing a list of trusted CA\n certificates (PEM format) these CAs will be used to verify the\n server certificate. For debian, you can set\n ``/etc/ssl/certs/ca-certificates.crt`` for using the system\n trusted CAs. For self-signed server, you can add your server\n certificate to the system store::\n\n cd /usr/local/share/ca-certificates/\n openssl s_client -starttls smtp \\\n -connect mail.example.net:587 -showcerts \\\n /dev/null \\\n | openssl x509 -outform PEM >mail.example.net.crt\n update-ca-certificates\n\n and used the updated ``/etc/ssl/certs/ca-certificates.crt``. Or\n directly use your ``/path/to/mail.example.net.crt``. Default is\n unset.\n\n multimailhook.smtpServerDebugLevel\n Integer number. Set to greater than 0 to activate debugging.\n\nmultimailhook.from, multimailhook.fromCommit, multimailhook.fromRefchange\n If set, use this value in the From: field of generated emails.\n ``fromCommit`` is used for commit emails, ``fromRefchange`` is\n used for refchange emails, and ``from`` is used as fall-back in\n all cases.\n\n The value for these variables can be either:\n\n - An email address, which will be used directly.\n\n - The value ``pusher``, in which case the pusher's address (if\n available) will be used.\n\n - The value ``author`` (meaningful only for ``fromCommit``), in which\n case the commit author's address will be used.\n\n If config values are unset, the value of the From: header is\n determined as follows:\n\n 1. (gitolite environment only)\n 1.a) If ``multimailhook.MailaddressMap`` is set, and is a path\n to an existing file (if relative, it is considered relative to\n the place where ``gitolite.conf`` is located), then this file\n should contain lines like::\n\n username Firstname Lastname \n\n git-multimail will then look for a line where ``$GL_USER``\n matches the ``username`` part, and use the rest of the line for\n the ``From:`` header.\n\n 1.b) Parse gitolite.conf, looking for a block of comments that\n looks like this::\n\n # BEGIN USER EMAILS\n # username Firstname Lastname \n # END USER EMAILS\n\n If that block exists, and there is a line between the BEGIN\n USER EMAILS and END USER EMAILS lines where the first field\n matches the gitolite username ($GL_USER), use the rest of the\n line for the From: header.\n\n 2. If the user.email configuration setting is set, use its value\n (and the value of user.name, if set).\n\n 3. Use the value of multimailhook.envelopeSender.\n\nmultimailhook.MailaddressMap\n (gitolite environment only)\n File to look for a ``From:`` address based on the user doing the\n push. Defaults to unset. See ``multimailhook.from`` for details.\n\nmultimailhook.administrator\n The name and/or email address of the administrator of the Git\n repository; used in FOOTER_TEMPLATE. Default is\n multimailhook.envelopesender if it is set; otherwise a generic\n string is used.\n\nmultimailhook.emailPrefix\n All emails have this string prepended to their subjects, to aid\n email filtering (though filtering based on the X-Git-* email\n headers is probably more robust). Default is the short name of\n the repository in square brackets; e.g., ``[myrepo]``. Set this\n value to the empty string to suppress the email prefix. You may\n use the placeholder ``%(repo_shortname)s`` for the short name of\n the repository.\n\nmultimailhook.emailMaxLines\n The maximum number of lines that should be included in the body of\n a generated email. If not specified, there is no limit. Lines\n beyond the limit are suppressed and counted, and a final line is\n added indicating the number of suppressed lines.\n\nmultimailhook.emailMaxLineLength\n The maximum length of a line in the email body. Lines longer than\n this limit are truncated to this length with a trailing ``[...]``\n added to indicate the missing text. The default is 500, because\n (a) diffs with longer lines are probably from binary files, for\n which a diff is useless, and (b) even if a text file has such long\n lines, the diffs are probably unreadable anyway. To disable line\n truncation, set this option to 0.\n\nmultimailhook.subjectMaxLength\n The maximum length of the subject line (i.e. the ``oneline`` field\n in templates, not including the prefix). Lines longer than this\n limit are truncated to this length with a trailing ``[...]`` added\n to indicate the missing text. This option The default is to use\n ``multimailhook.emailMaxLineLength``. This option avoids sending\n emails with overly long subject lines, but should not be needed if\n the commit messages follow the Git convention (one short subject\n line, then a blank line, then the message body). To disable line\n truncation, set this option to 0.\n\nmultimailhook.maxCommitEmails\n The maximum number of commit emails to send for a given change.\n When the number of patches is larger that this value, only the\n summary refchange email is sent. This can avoid accidental\n mailbombing, for example on an initial push. To disable commit\n emails limit, set this option to 0. The default is 500.\n\nmultimailhook.excludeMergeRevisions\n When sending out revision emails, do not consider merge commits (the\n functional equivalent of `rev-list --no-merges`).\n The default is `false` (send merge commit emails).\n\nmultimailhook.emailStrictUTF8\n If this boolean option is set to `true`, then the main part of the\n email body is forced to be valid UTF-8. Any characters that are\n not valid UTF-8 are converted to the Unicode replacement\n character, U+FFFD. The default is `true`.\n\n This option is ineffective with Python 3, where non-UTF-8\n characters are unconditionally replaced.\n\nmultimailhook.diffOpts\n Options passed to ``git diff-tree`` when generating the summary\n information for ReferenceChange emails. Default is ``--stat\n --summary --find-copies-harder``. Add -p to those options to\n include a unified diff of changes in addition to the usual summary\n output. Shell quoting is allowed; see ``multimailhook.logOpts`` for\n details.\n\nmultimailhook.graphOpts\n Options passed to ``git log --graph`` when generating graphs for the\n reference change summary emails (used only if refchangeShowGraph\n is true). The default is '--oneline --decorate'.\n\n Shell quoting is allowed; see logOpts for details.\n\nmultimailhook.logOpts\n Options passed to ``git log`` to generate additional info for\n reference change emails (used only if refchangeShowLog is set).\n For example, adding -p will show each commit's complete diff. The\n default is empty.\n\n Shell quoting is allowed; for example, a log format that contains\n spaces can be specified using something like::\n\n git config multimailhook.logopts '--pretty=format:\"%h %aN <%aE>%n%s%n%n%b%n\"'\n\n If you want to set this by editing your configuration file\n directly, remember that Git requires double-quotes to be escaped\n (see git-config(1) for more information)::\n\n [multimailhook]\n logopts = --pretty=format:\\\"%h %aN <%aE>%n%s%n%n%b%n\\\"\n\nmultimailhook.commitLogOpts\n Options passed to ``git log`` to generate additional info for\n revision change emails. For example, adding --ignore-all-spaces\n will suppress whitespace changes. The default options are ``-C\n --stat -p --cc``. Shell quoting is allowed; see\n multimailhook.logOpts for details.\n\nmultimailhook.dateSubstitute\n String to use as a substitute for ``Date:`` in the output of ``git\n log`` while formatting commit messages. This is useful to avoid\n emitting a line that can be interpreted by mailers as the start of\n a cited message (Zimbra webmail in particular). Defaults to\n ``CommitDate:``. Set to an empty string or ``none`` to deactivate\n the behavior.\n\nmultimailhook.emailDomain\n Domain name appended to the username of the person doing the push\n to convert it into an email address\n (via ``\"%s@%s\" % (username, emaildomain)``). More complicated\n schemes can be implemented by overriding Environment and\n overriding its get_pusher_email() method.\n\nmultimailhook.replyTo, multimailhook.replyToCommit, multimailhook.replyToRefchange\n Addresses to use in the Reply-To: field for commit emails\n (replyToCommit) and refchange emails (replyToRefchange).\n multimailhook.replyTo is used as default when replyToCommit or\n replyToRefchange is not set. The shortcuts ``pusher`` and\n ``author`` are allowed with the same semantics as for\n ``multimailhook.from``. In addition, the value ``none`` can be\n used to omit the ``Reply-To:`` field.\n\n The default is ``pusher`` for refchange emails, and ``author`` for\n commit emails.\n\nmultimailhook.quiet\n Do not output the list of email recipients from the hook\n\nmultimailhook.stdout\n For debugging, send emails to stdout rather than to the\n mailer. Equivalent to the --stdout command line option\n\nmultimailhook.scanCommitForCc\n If this option is set to true, than recipients from lines in commit body\n that starts with ``CC:`` will be added to CC list.\n Default: false\n\nmultimailhook.combineWhenSingleCommit\n If this option is set to true and a single new commit is pushed to\n a branch, combine the summary and commit email messages into a\n single email.\n Default: true\n\nmultimailhook.refFilterInclusionRegex, multimailhook.refFilterExclusionRegex, multimailhook.refFilterDoSendRegex, multimailhook.refFilterDontSendRegex\n **Warning:** these options are experimental. They should work, but\n the user-interface is not stable yet (in particular, the option\n names may change). If you want to participate in stabilizing the\n feature, please contact the maintainers and/or send pull-requests.\n If you are happy with the current shape of the feature, please\n report it too.\n\n Regular expressions that can be used to limit refs for which email\n updates will be sent. It is an error to specify both an inclusion\n and an exclusion regex. If a ``refFilterInclusionRegex`` is\n specified, emails will only be sent for refs which match this\n regex. If a ``refFilterExclusionRegex`` regex is specified,\n emails will be sent for all refs except those that match this\n regex (or that match a predefined regex specific to the\n environment, such as \"^refs/notes\" for most environments and\n \"^refs/notes|^refs/changes\" for the gerrit environment).\n\n The expressions are matched against the complete refname, and is\n considered to match if any substring matches. For example, to\n filter-out all tags, set ``refFilterExclusionRegex`` to\n ``^refs/tags/`` (note the leading ``^`` but no trailing ``$``). If\n you set ``refFilterExclusionRegex`` to ``master``, then any ref\n containing ``master`` will be excluded (the ``master`` branch, but\n also ``refs/tags/master`` or ``refs/heads/foo-master-bar``).\n\n ``refFilterDoSendRegex`` and ``refFilterDontSendRegex`` are\n analogous to ``refFilterInclusionRegex`` and\n ``refFilterExclusionRegex`` with one difference: with\n ``refFilterDoSendRegex`` and ``refFilterDontSendRegex``, commits\n introduced by one excluded ref will not be considered as new when\n they reach an included ref. Typically, if you add a branch ``foo``\n to ``refFilterDontSendRegex``, push commits to this branch, and\n later merge branch ``foo`` into ``master``, then the notification\n email for ``master`` will contain a commit email only for the\n merge commit. If you include ``foo`` in\n ``refFilterExclusionRegex``, then at the time of merge, you will\n receive one commit email per commit in the branch.\n\n These variables can be multi-valued, like::\n\n [multimailhook]\n refFilterExclusionRegex = ^refs/tags/\n refFilterExclusionRegex = ^refs/heads/master$\n\n You can also provide a whitespace-separated list like::\n\n [multimailhook]\n refFilterExclusionRegex = ^refs/tags/ ^refs/heads/master$\n\n Both examples exclude tags and the master branch, and are\n equivalent to::\n\n [multimailhook]\n refFilterExclusionRegex = ^refs/tags/|^refs/heads/master$\n\n ``refFilterInclusionRegex`` and ``refFilterExclusionRegex`` are\n strictly stronger than ``refFilterDoSendRegex`` and\n ``refFilterDontSendRegex``. In other words, adding a ref to a\n DoSend/DontSend regex has no effect if it is already excluded by a\n Exclusion/Inclusion regex.\n\nmultimailhook.logFile, multimailhook.errorLogFile, multimailhook.debugLogFile\n\n When set, these variable designate path to files where\n git-multimail will log some messages. Normal messages and error\n messages are sent to ``logFile``, and error messages are also sent\n to ``errorLogFile``. Debug messages and all other messages are\n sent to ``debugLogFile``. The recommended way is to set only one\n of these variables, but it is also possible to set several of them\n (part of the information is then duplicated in several log files,\n for example errors are duplicated to all log files).\n\n Relative path are relative to the Git repository where the push is\n done.\n\nmultimailhook.verbose\n\n Verbosity level of git-multimail on its standard output. By\n default, show only error and info messages. If set to true, show\n also debug messages.\n\nEmail filtering aids\n--------------------\n\nAll emails include extra headers to enable fine tuned filtering and\ngive information for debugging. All emails include the headers\n``X-Git-Host``, ``X-Git-Repo``, ``X-Git-Refname``, and ``X-Git-Reftype``.\nReferenceChange emails also include headers ``X-Git-Oldrev`` and ``X-Git-Newrev``;\nRevision emails also include header ``X-Git-Rev``.\n\n\nCustomizing email contents\n--------------------------\n\ngit-multimail mostly generates emails by expanding templates. The\ntemplates can be customized. To avoid the need to edit\n``git_multimail.py`` directly, the preferred way to change the templates\nis to write a separate Python script that imports ``git_multimail.py`` as\na module, then replaces the templates in place. See the provided\npost-receive script for an example of how this is done.\n\n\nCustomizing git-multimail for your environment\n----------------------------------------------\n\ngit-multimail is mostly customized via an \"environment\" that describes\nthe local environment in which Git is running. Two types of\nenvironment are built in:\n\nGenericEnvironment\n a stand-alone Git repository.\n\nGitoliteEnvironment\n a Git repository that is managed by gitolite_. For such\n repositories, the identity of the pusher is read from\n environment variable $GL_USER, the name of the repository is read\n from $GL_REPO (if it is not overridden by multimailhook.reponame),\n and the From: header value is optionally read from gitolite.conf\n (see multimailhook.from).\n\nBy default, git-multimail assumes GitoliteEnvironment if $GL_USER and\n$GL_REPO are set, and otherwise assumes GenericEnvironment.\nAlternatively, you can choose one of these two environments explicitly\nby setting a ``multimailhook.environment`` config setting (which can\nhave the value `generic` or `gitolite`) or by passing an --environment\noption to the script.\n\nIf you need to customize the script in ways that are not supported by\nthe existing environments, you can define your own environment class\nclass using arbitrary Python code. To do so, you need to import\n``git_multimail.py`` as a Python module, as demonstrated by the example\npost-receive script. Then implement your environment class; it should\nusually inherit from one of the existing Environment classes and\npossibly one or more of the EnvironmentMixin classes. Then set the\n``environment`` variable to an instance of your own environment class\nand pass it to ``run_as_post_receive_hook()``.\n\nThe standard environment classes, GenericEnvironment and\nGitoliteEnvironment, are in fact themselves put together out of a\nnumber of mixin classes, each of which handles one aspect of the\ncustomization. For the finest control over your configuration, you\ncan specify exactly which mixin classes your own environment class\nshould inherit from, and override individual methods (or even add your\nown mixin classes) to implement entirely new behaviors. If you\nimplement any mixins that might be useful to other people, please\nconsider sharing them with the community!\n\n\nGetting involved\n----------------\n\nPlease, read ``__ for instructions on how to\ncontribute to git-multimail.\n\n\nFootnotes\n---------\n\n.. [1] Because of the way information is passed to update hooks, the\n script's method of determining whether a commit has already\n been seen does not work when it is used as an ``update`` script.\n In particular, no notification email will be generated for a\n new commit that is added to multiple references in the same\n push. A workaround is to use --force-send to force sending the\n emails.\n\n.. _gitolite: https://github.com/sitaramc/gitolite\n", "description_content_type": "", "docs_url": null, "download_url": "", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/git-multimail/git-multimail", "keywords": "git hook email", "license": "GPLv2", "maintainer": "", "maintainer_email": "", "name": "git-multimail", "package_url": "https://pypi.org/project/git-multimail/", "platform": "", "project_url": "https://pypi.org/project/git-multimail/", "project_urls": { "Homepage": "https://github.com/git-multimail/git-multimail" }, "release_url": "https://pypi.org/project/git-multimail/1.5.0.post1/", "requires_dist": null, "requires_python": "", "summary": "Send notification emails for Git pushes", "version": "1.5.0.post1" }, "last_serial": 4723181, "releases": { "0.9.0": [], "1.1.0-1": [ { "comment_text": "", "digests": { "md5": "eb88a3626c8a59983fccef4eb4b5ac3d", "sha256": "22ffa62326e8c40db6079adbcaae843e97a399332e256736733c670d90345184" }, "downloads": -1, "filename": "git-multimail-1.1.0-1.tar.gz", "has_sig": false, "md5_digest": "eb88a3626c8a59983fccef4eb4b5ac3d", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 75179, "upload_time": "2015-06-18T18:08:44", "url": "https://files.pythonhosted.org/packages/cb/66/c4f5a8922c986dc5d90a1f7d056e4b1a7c7c765d598d66a50410c6d305ce/git-multimail-1.1.0-1.tar.gz" } ], "1.1.1": [ { "comment_text": "", "digests": { "md5": "c0b0ebc90a3b5b8c0553282cfabf3699", "sha256": "2380f0556def8b60368a6b02eaaae307204a70360d618e426143f2637dd88c03" }, "downloads": -1, "filename": "git-multimail-1.1.1.tar.gz", "has_sig": false, "md5_digest": "c0b0ebc90a3b5b8c0553282cfabf3699", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 75235, "upload_time": "2015-07-03T14:00:36", "url": "https://files.pythonhosted.org/packages/ca/d3/0f9e919f1d6da051115f3f2d327b005028d8426716f5c62f983350e0c215/git-multimail-1.1.1.tar.gz" } ], "1.2.0": [ { "comment_text": "", "digests": { "md5": "568e03a233517518c970ceeda58462fc", "sha256": "bc0da0ddbce8eba5bb63634561541b57980be017711fa520613c8606af56786c" }, "downloads": -1, "filename": "git-multimail-1.2.0.tar.gz", "has_sig": false, "md5_digest": "568e03a233517518c970ceeda58462fc", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 76524, "upload_time": "2015-10-11T18:45:20", "url": "https://files.pythonhosted.org/packages/96/a1/012e48bb4c581ea0c2df62404b11880d03d00e223abd9e7f58e366444dfb/git-multimail-1.2.0.tar.gz" } ], "1.3.0": [ { "comment_text": "", "digests": { "md5": "6716ce0ee000f85f317b73801c57117c", "sha256": "7d9bbead2c9bb651be8df9213a4e4ba876dfdefdc74eb444c21fa44d848a693d" }, "downloads": -1, "filename": "git-multimail-1.3.0.tar.gz", "has_sig": false, "md5_digest": "6716ce0ee000f85f317b73801c57117c", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 83188, "upload_time": "2016-05-03T08:36:45", "url": "https://files.pythonhosted.org/packages/fa/43/7d18d79aea5f3a9f4907908e0352a046f2f0974a11d696eb97837decf282/git-multimail-1.3.0.tar.gz" } ], "1.3.1": [ { "comment_text": "", "digests": { "md5": "1221ded8a5710120ef1b4ef9cd13da5f", "sha256": "dbab0d0f69c8b4ec59d770eb30263bb38f4d150f8d0f6eb4bacdda6d16db1f88" }, "downloads": -1, "filename": "git-multimail-1.3.1.tar.gz", "has_sig": false, "md5_digest": "1221ded8a5710120ef1b4ef9cd13da5f", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 83475, "upload_time": "2016-05-13T17:01:06", "url": "https://files.pythonhosted.org/packages/a4/06/3828306b4cb9b6dea5b8ca9ca63fbc53c35bac2589cb9b68854aa46758fd/git-multimail-1.3.1.tar.gz" } ], "1.4.0": [ { "comment_text": "", "digests": { "md5": "2de8c2bbb148fd00a971153f29d05d08", "sha256": "4ba7616091a4ed3181010ff0565b90e315c36aee2ffb183a0d6e05a494017b9b" }, "downloads": -1, "filename": "git-multimail-1.4.0.tar.gz", "has_sig": false, "md5_digest": "2de8c2bbb148fd00a971153f29d05d08", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 89287, "upload_time": "2016-08-17T06:42:01", "url": "https://files.pythonhosted.org/packages/13/26/989eaa37733f7406a2efee00e6a52a0665b1a1cf74ae60c47819849665d3/git-multimail-1.4.0.tar.gz" } ], "1.5.0": [ { "comment_text": "", "digests": { "md5": "78b5bc0d2efd83246c9f7a6d2d54c744", "sha256": "de4704abcbc6c8ba00e9e3ab46191d9adb51628e918c628efdbab7d9e07e23b2" }, "downloads": -1, "filename": "git-multimail-1.5.0.tar.gz", "has_sig": false, "md5_digest": "78b5bc0d2efd83246c9f7a6d2d54c744", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 91996, "upload_time": "2019-01-08T10:27:58", "url": "https://files.pythonhosted.org/packages/cc/59/b7c8f73c3c46fc5102f9fa2843b7430192ae8048f97fdec043d865e1ea09/git-multimail-1.5.0.tar.gz" } ], "1.5.0.post1": [ { "comment_text": "", "digests": { "md5": "a8465b4a8dd062fcc43f9a80453ee2ef", "sha256": "3e9944d94df406ec67f4d13d3f890159dbb33255dc696f10bfdc2a70945e79fe" }, "downloads": -1, "filename": "git-multimail-1.5.0.post1.tar.gz", "has_sig": false, "md5_digest": "a8465b4a8dd062fcc43f9a80453ee2ef", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 91753, "upload_time": "2019-01-21T20:31:51", "url": "https://files.pythonhosted.org/packages/ec/1e/e72afcddf5defdd873bdd40c92f4a6bb2934722eaa0c747c2c5dfb13a68f/git-multimail-1.5.0.post1.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "a8465b4a8dd062fcc43f9a80453ee2ef", "sha256": "3e9944d94df406ec67f4d13d3f890159dbb33255dc696f10bfdc2a70945e79fe" }, "downloads": -1, "filename": "git-multimail-1.5.0.post1.tar.gz", "has_sig": false, "md5_digest": "a8465b4a8dd062fcc43f9a80453ee2ef", "packagetype": "sdist", "python_version": "source", "requires_python": null, "size": 91753, "upload_time": "2019-01-21T20:31:51", "url": "https://files.pythonhosted.org/packages/ec/1e/e72afcddf5defdd873bdd40c92f4a6bb2934722eaa0c747c2c5dfb13a68f/git-multimail-1.5.0.post1.tar.gz" } ] }