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