GIT-SEND-EMAIL(1) | Git Manual | GIT-SEND-EMAIL(1) |
git-send-email - Send a collection of patches as emails
git send-email [<options>] <file|directory>... git send-email [<options>] <format-patch options> git send-email --dump-aliases
Takes the patches given on the command line and emails them out. Patches can be specified as files, directories (which will send all files in the directory), or directly as a revision list. In the last case, any format accepted by git-format-patch(1) can be passed to git send-email, as well as options understood by git-format-patch(1).
The header of the email is configurable via command-line options. If not specified on the command line, the user will be prompted with a ReadLine enabled interface to provide the necessary information.
There are two formats accepted for patch files:
This is what git-format-patch(1) generates. Most headers and MIME formatting are ignored.
This format expects the first line of the file to contain the "Cc:" value and the "Subject:" of the message as the second line.
--annotate
--bcc=<address>,...
This option may be specified multiple times.
--cc=<address>,...
This option may be specified multiple times.
--compose
When --compose is used, git send-email will use the From, Subject, and In-Reply-To headers specified in the message. If the body of the message (what you type after the headers and a blank line) only contains blank (or Git: prefixed) lines, the summary won’t be sent, but From, Subject, and In-Reply-To headers will be used unless they are removed.
Missing From or In-Reply-To headers will be prompted for.
See the CONFIGURATION section for sendemail.multiEdit.
--from=<address>
--reply-to=<address>
--in-reply-to=<identifier>
So for example when --thread and --no-chain-reply-to are specified, the second and subsequent patches will be replies to the first one like in the illustration below where [PATCH v2 0/3] is in reply to [PATCH 0/2]:
[PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation
Only necessary if --compose is also set. If --compose is not set, this will be prompted for.
--subject=<string>
--to=<address>,...
This option may be specified multiple times.
--8bit-encoding=<encoding>
Note that no attempts whatsoever are made to validate the encoding.
--compose-encoding=<encoding>
--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)
Default is the value of the sendemail.transferEncoding configuration value; if that is unspecified, default to auto.
--xmailer, --no-xmailer
--envelope-sender=<address>
--sendmail-cmd=<command>
--smtp-encryption=<encryption>
--smtp-domain=<FQDN>
--smtp-auth=<mechanisms>
$ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...
If at least one of the specified mechanisms matches the ones advertised by the SMTP server and if it is supported by the utilized SASL library, the mechanism is used for authentication. If neither sendemail.smtpAuth nor --smtp-auth is specified, all mechanisms supported by the SASL library can be used. The special value none maybe specified to completely disable authentication independently of --smtp-user
--smtp-pass[=<password>]
Furthermore, passwords need not be specified in configuration files or on the command line. If a username has been specified (with --smtp-user or a sendemail.smtpUser), but no password has been specified (with --smtp-pass or sendemail.smtpPass), then a password is obtained using git-credential.
--no-smtp-auth
--smtp-server=<host>
For backward compatibility, this option can also specify a full pathname of a sendmail-like program instead; the program must support the -i option. This method does not support passing arguments or using plain command names. For those use cases, consider using --sendmail-cmd instead.
--smtp-server-port=<port>
--smtp-server-option=<option>
The --smtp-server-option option must be repeated for each option you want to pass to the server. Likewise, different lines in the configuration files must be used for each option.
--smtp-ssl
--smtp-ssl-cert-path
--smtp-user=<user>
--smtp-debug=0|1
--batch-size=<num>
--relogin-delay=<int>
--no-[to|cc|bcc]
--no-identity
--to-cmd=<command>
--cc-cmd=<command>
--[no-]chain-reply-to
--identity=<identity>
--[no-]signed-off-by-cc
--[no-]cc-cover
--[no-]to-cover
--suppress-cc=<category>
Default is the value of sendemail.suppresscc configuration value; if that is unspecified, default to self if --suppress-from is specified, as well as body if --no-signed-off-cc is specified.
--[no-]suppress-from
--[no-]thread
If disabled with "--no-thread", those headers will not be added (unless specified with --in-reply-to). Default is the value of the sendemail.thread configuration value; if that is unspecified, default to --thread.
It is up to the user to ensure that no In-Reply-To header already exists when git send-email is asked to add it (especially note that git format-patch can be configured to do the threading itself). Failure to do so may not produce the expected result in the recipient’s MUA.
--confirm=<mode>
Default is the value of sendemail.confirm configuration value; if that is unspecified, default to auto unless any of the suppress options have been specified, in which case default to compose.
--dry-run
--[no-]format-patch
--quiet
--[no-]validate
Default is the value of sendemail.validate; if this is not set, default to --validate.
--force
--dump-aliases
Everything below this line in this section is selectively included from the git-config(1) documentation. The content is the same as what’s found there:
sendemail.identity
sendemail.smtpEncryption
sendemail.smtpsslcertpath
sendemail.<identity>.*
sendemail.multiEdit
sendemail.confirm
sendemail.aliasesFile
sendemail.aliasFileType
What an alias file in each format looks like can be found in the documentation of the email program of the same name. The differences and limitations from the standard formats are described below:
sendmail
sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd, sendemail.chainReplyTo, sendemail.envelopeSender, sendemail.from, sendemail.signedoffbycc, sendemail.smtpPass, sendemail.suppresscc, sendemail.suppressFrom, sendemail.to, sendemail.tocmd, sendemail.smtpDomain, sendemail.smtpServer, sendemail.smtpServerPort, sendemail.smtpServerOption, sendemail.smtpUser, sendemail.thread, sendemail.transferEncoding, sendemail.validate, sendemail.xmailer
sendemail.signedoffcc (deprecated)
sendemail.smtpBatchSize
sendemail.smtpReloginDelay
sendemail.forbidSendmailVariables
To use git send-email to send your patches through the GMail SMTP server, edit ~/.gitconfig to specify your account settings:
[sendemail]
smtpEncryption = tls
smtpServer = smtp.gmail.com
smtpUser = yourname@gmail.com
smtpServerPort = 587
If you have multi-factor authentication set up on your Gmail account, you will need to generate an app-specific password for use with git send-email. Visit https://security.google.com/settings/security/apppasswords to create it.
If you do not have multi-factor authentication set up on your Gmail account, you will need to allow less secure app access. Visit https://myaccount.google.com/lesssecureapps to enable it.
Once your commits are ready to be sent to the mailing list, run the following commands:
$ git format-patch --cover-letter -M origin/master -o outgoing/ $ edit outgoing/0000-* $ git send-email outgoing/*
The first time you run it, you will be prompted for your credentials. Enter the app-specific or your regular password as appropriate. If you have credential helper configured (see git-credential(1)), the password will be saved in the credential store so you won’t have to type it the next time.
Note: the following core Perl modules that may be installed with your distribution of Perl are required: MIME::Base64, MIME::QuotedPrint, Net::Domain and Net::SMTP. These additional Perl modules are also required: Authen::SASL and Mail::Address.
git-format-patch(1), git-imap-send(1), mbox(5)
Part of the git(1) suite
06/06/2021 | Git 2.32.0 |