GIT-SEND-EMAIL(1)

📦
version 2.56.0 · 26 versions
, in fedora 43, fedora 44

🌸 GIT-SEND-EMAIL(1) 🌸 — the Git Manual, bestie edition

okay so we're doing git-send-email today and honestly? it's giving "i mass-email patches to maintainers and it works every time" 💅 it lives in the Git Manual, section 1, and it is SO much less scary than it looks. sit with me.

✨ NAME ✨

git-send-email — send a whole collection of patches as emails 📧✨

🎀 SYNOPSIS 🎀

git send-email [<options>] (<file>|<directory>)...
git send-email [<options>] <format-patch-options>
git send-email --dump-aliases
git send-email --translate-aliases

🦋 DESCRIPTION 🦋

So what it does: it takes the patches you hand it on the command line and emails them out. that's it, that's the whole vibe. 💌

You can give it patches as:

  • files 📄
  • directories 📁 — and yes, it'll send every single file in that directory, no cap
  • a revision list, directly 🌈

In that last case, anything git-format-patch(1) accepts can be passed straight to git send-email, and so can every option that git-format-patch(1) understands. slay.

The email header is configurable via command-line options. And if you don't specify it on the command line, you'll get prompted through a ReadLine-enabled interface to hand over the info it needs. it will literally just ask you, bestie, and you will answer. 🫶

There are two formats accepted for patch files:

  1. mbox format files 📦

This is the one git-format-patch(1) generates. Most headers and MIME formatting get ignored.

  1. The original format used by Greg Kroah-Hartman's send_lots_of_email.pl script 🧚

This format expects the first line of the file to contain the Cc: value, and the Subject: of the message to be the second line. that's the whole contract, iykyk.

✨ OPTIONS ✨

💅 Composing 💅

  • --annotate — review and edit every single patch you're about to send, main character energy. Default is the value of sendemail.annotate. For sendemail.multiEdit, go look at the CONFIGURATION section. 📝
  • --bcc=<address>,... — set a Bcc: value for each email. Default is the value of sendemail.bcc.

You can specify this option multiple times. 🙈

  • --cc=<address>,... — set a starting Cc: value for each email. Default is the value of sendemail.cc.

You can specify this option multiple times. 🙈

  • --compose — pops open a text editor (see GIT_EDITOR in git-var(1)) so you can write an introductory message for the patch series. ✍️✨

When --compose is used, git send-email will use the From, To, Cc, Bcc, Subject, Reply-To, and In-Reply-To headers specified in the message. And if the body of the message (aka everything you type after the headers and that blank line) only contains blank lines or Git:-prefixed lines, then the summary won't be sent — but those headers up above will still be used, unless you remove them.

Missing From or In-Reply-To headers will be prompted for. 🗣️

For sendemail.multiEdit, see the CONFIGURATION section.

  • --from=<address> — specify the sender of the emails. If you don't say it on the command line, the value of the sendemail.from configuration option is used. If neither the command-line option nor sendemail.from are set, then you'll get prompted for it. And the default for that prompt will be the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that one isn't set, as returned by git var -l. 🪪
  • --reply-to=<address> — specify where replies from recipients should go. Use this when you want replies to messages to land somewhere other than whatever you set with the --from parameter. ↩️
  • --in-reply-to=<identifier> — makes the first mail (or all the mails, if you're using --no-thread) appear as a reply to the given Message-ID, which avoids breaking threads when you're providing a new patch series. The second and subsequent emails will be sent as replies according to the --[no-]chain-reply-to setting. 🧵

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. 👑

  • --outlook-id-fix, --no-outlook-id-fix — okay so here's the tea 🍵: Microsoft Outlook SMTP servers discard the Message-ID sent via email and assign a new random Message-ID, which breaks threads. rude, honestly.

With --outlook-id-fix, git send-email uses a mechanism specific to Outlook servers to learn the Message-ID the server assigned, so it can fix the threading. Use it only when you know that the server reports the rewritten Message-ID the same way Outlook servers do.

Without this option specified, the fix is done by default when talking to smtp.office365.com or smtp-mail.outlook.com. Use --no-outlook-id-fix to disable it even when talking to those two servers. 💀

  • --subject=<string> — specify the initial subject of the email thread. Only necessary if --compose is also set. If --compose is not set, this will be prompted for. 💬
  • --to=<address>,... — specify the primary recipient of the emails generated. Generally this is gonna be the upstream maintainer of the project involved. Default is the value of the sendemail.to configuration value; and if that's unspecified, and --to-cmd is not specified, this will be prompted for. 👑

You can specify this option multiple times. 🙈

  • --8bit-encoding=<encoding> — when you run into a non-ASCII message or subject that doesn't declare its encoding, this adds headers/quoting to indicate it's encoded in <encoding>. Default is the value of sendemail.assume8bitEncoding; if that's unspecified, this will be prompted for if any non-ASCII files are encountered.
⚠️ Note that no attempts whatsoever are made to validate the encoding. it does not check. it does not care. it just trusts you. 💀
  • --compose-encoding=<encoding> — specify the encoding of the compose message. Default is the value of sendemail.composeEncoding; if that's unspecified, UTF-8 is assumed. 🌈
  • --transfer-encoding=(7bit|8bit|quoted-printable|base64|auto) — specify the transfer encoding used to send the message over SMTP.
    • 7bit will fail upon encountering a non-ASCII message.
    • quoted-printable can be useful when the repository contains files that contain carriage returns, but it makes the raw patch email file (as saved from an MUA) much harder to inspect manually.
    • base64 is even more fool proof, but also even more opaque.
    • auto will use 8bit when possible, and quoted-printable otherwise.

Default is the value of the sendemail.transferEncoding configuration value; if that's unspecified, default to auto. 🎀

  • --xmailer, --no-xmailer — add (or prevent adding) the X-Mailer: header. By default the header is added, but it can be turned off by setting the sendemail.xmailer configuration variable to false. ✉️

📤 Sending 📤

  • --envelope-sender=<address> — specify the envelope sender used to send the emails. This is useful if your default address isn't the address that's subscribed to a list. To use the From address, set the value to auto. If you use the sendmail binary, you must have suitable privileges for the -f parameter. Default is the value of the sendemail.envelopeSender configuration variable; if that's unspecified, choosing the envelope sender is left to your MTA. 🫡
  • --sendmail-cmd=<command> — specify a command to run to send the email. The command should be sendmail-like; specifically, it must support the -i option. The command will be executed in the shell if necessary. Default is the value of sendemail.sendmailCmd. If unspecified, and if --smtp-server is also unspecified, git send-email will search for sendmail in /usr/sbin, /usr/lib and $PATH. 🔍
  • --smtp-encryption=<encryption> — specify in what way encrypting begins for the SMTP connection. Valid values are ssl and tls. Any other value reverts to plain (unencrypted) SMTP, which defaults to port 25.

Despite the names, both values will use the same newer version of TLS, but for historic reasons they have these names.

  • ssl refers to "implicit" encryption (sometimes called SMTPS), which uses port 465 by default.
  • tls refers to "explicit" encryption (often known as STARTTLS), which uses port 25 by default.

Other ports might be used by the SMTP server, which are not the default. A commonly found alternative port for tls and unencrypted is 587. You need to check your provider's documentation or your server configuration to make sure for your own case. Default is the value of sendemail.smtpEncryption. 🔐

  • --smtp-domain=<FQDN> — specify the Fully Qualified Domain Name (FQDN) used in the HELO/EHLO command to the SMTP server. Some servers require the FQDN to match your IP address. If not set, git send-email attempts to determine your FQDN automatically. Default is the value of sendemail.smtpDomain. 🏠
  • --smtp-auth=<mechanisms> — whitespace-separated list of allowed SMTP-AUTH mechanisms. This setting forces using only the listed mechanisms. Example:
$ 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's supported by the utilized SASL library, that 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 may be specified to completely disable authentication, independently of --smtp-user. 🔑

  • --smtp-pass[=<password>] — password for SMTP-AUTH. The argument is optional: if no argument is specified, then the empty string is used as the password. Default is the value of sendemail.smtpPass, however --smtp-pass always overrides this value. 🤫

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(1). 🪄

  • --no-smtp-auth — disable SMTP authentication. Short hand for --smtp-auth=none. 🚫
  • --smtp-server=<host> — specify the outgoing SMTP server to use (e.g. smtp.example.com or a raw IP address). If unspecified, and if --sendmail-cmd is also unspecified, the default is to search for sendmail in /usr/sbin, /usr/lib and $PATH if such a program is available, falling back to localhost otherwise. 🌐

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. 💡

…and bestie, there is SO much more where that came from. stay tuned, we're not done. 💜

  • --smtp-server-port=<port> — bestie, this is how you pick a port that isn't the default one. SMTP servers usually camp out on smtp port 25, but they might also be vibing on submission port 587, or the super common SSL smtp port 465. And yes, symbolic port names are accepted too (so like submission instead of 587, cute right?). You can also set the port with the sendemail.smtpServerPort configuration variable. ✨
  • --smtp-server-option=<option> — set the outgoing SMTP server option to use. The default can be specified by the sendemail.smtpServerOption configuration option.
okay so this one's a little needy: --smtp-server-option must be repeated for every single option you want to pass to the server. Same deal in config files — every option gets its own line. No bundling, no shortcuts. 💅
  • --smtp-ssl — the legacy alias for --smtp-encryption ssl. It's giving "we keep it around for the old heads" 🫶
  • --smtp-ssl-cert-path <path> — path to a store of trusted CA certificates, used for SMTP SSL/TLS certificate validation. It's either a directory that's been processed by c_rehash, or a single file with one or more PEM format certificates concatenated together. For the details on those, go read the description of the -CAfile <file> and the -CApath <dir> options of https://docs.openssl.org/master/man1/openssl-verify/ (that's OpenSSL's verify(1) manual page, iykyk). Set it to an empty string to disable certificate verification (⚠️ do that on purpose, not by accident). Defaults to the value of the sendemail.smtpSSLCertPath configuration variable, if set, or the backing SSL library's compiled-in default otherwise — which should be the best choice on most platforms. 👑
  • --smtp-ssl-client-cert <path> — path to the client certificate file to present if the server asks for it. This option is required when the server is set up to verify client certificates. If the corresponding private key is not included in the file, you gotta supply it using the sendemail.smtpSSLClientKey configuration variable or the --smtp-ssl-client-key option. Defaults to the value of the sendemail.smtpSSLClientCert configuration variable, if set. 🎀
  • --smtp-ssl-client-key <path> — path to the client private key file that corresponds to the client certificate. To avoid misconfiguration, this option must be used in conjunction with the sendemail.smtpSSLClientKey configuration variable or the --smtp-ssl-client-cert option. If the client key is included in the client certificate, the choice of private key depends on the format of the certificate — visit https://metacpan.org/pod/IO::Socket::SSL for more details. Defaults to the value of the sendemail.smtpSSLClientKey configuration variable, if set. 🔐
  • --smtp-user=<user> — username for SMTP-AUTH. The default is the value of sendemail.smtpUser; and if a username is not specified (with --smtp-user or sendemail.smtpUser), then authentication is simply not attempted. No username, no auth, no drama. 💜
  • --smtp-debug=(0|1) — turn debug output on (1) or off (0). When it's on, SMTP commands and replies get printed out. Genuinely useful for debugging TLS connection and authentication problems. It's giving detective mode 🔍
  • --imap-sent-folder=<folder> — some email providers (e.g. iCloud) do not send a copy of the emails you send using SMTP to the Sent folder or similar in your mailbox. Rude honestly. So use this option to have git imap-send send a copy of the emails to the folder you specify here. You can run git imap-send --list to get a list of valid folder names, including the correct name of the Sent folder in your mailbox. You can also use this option to send emails to a dedicated IMAP folder of your choice. 🌸

This feature requires setting up git imap-send. See git-imap-send(1) for instructions.

  • --use-imap-only, --no-use-imap-only — if this is set, all emails will only be copied to the IMAP folder specified with --imap-sent-folder or sendemail.imapSentFolder, and will not be sent to the recipients. Super useful if you just want to create a draft of the emails and use another email client to send them. If disabled with --no-use-imap-only, the emails will be sent like usual. Disabled by default, but the sendemail.useImapOnly configuration variable can be used to enable it. ✨

This feature requires setting up git imap-send. See git-imap-send(1) for instructions.

  • --batch-size=<num> — some email servers (e.g. smtp.163.com) limit the number of emails you can send per session (connection), and that will lead to a failure when you're sending many messages. With this option, send-email will disconnect after sending <num> messages, wait for a few seconds (see --relogin-delay), and reconnect — working around the limit like a legend. You may want to use some form of credential helper to avoid having to retype your password every time this happens. Defaults to the sendemail.smtpBatchSize configuration variable. 🔥
  • --relogin-delay=<int> — wait <int> seconds before reconnecting to the SMTP server. Used together with the --batch-size option. Defaults to the sendemail.smtpReloginDelay configuration variable. ⏳

✨ Automating ✨

  • --no-to, --no-cc, --no-bcc — clear any list of To:, Cc:, Bcc: addresses that were previously set via config. Fresh slate energy 🧹
  • --no-identity — clear the previously read value of sendemail.identity set via config, if any.
  • --to-cmd=<command> — specify a command to execute once per patch file, which should generate patch-file-specific To: entries. The output of this command must be a single email address per line. Default is the value of the sendemail.toCmd configuration value.
  • --cc-cmd=<command> — specify a command to execute once per patch file, which should generate patch-file-specific Cc: entries. The output of this command must be a single email address per line. Default is the value of the sendemail.ccCmd configuration value.
  • --header-cmd=<command> — specify a command that's executed once per outgoing message, and outputs RFC 2822 style header lines to be inserted into them. When the sendemail.headerCmd configuration variable is set, its value is always used. When --header-cmd is provided at the command line, its value takes precedence over the sendemail.headerCmd configuration variable. Command line stays winning 💅
  • --no-header-cmd — disable any header command currently in use.
  • --chain-reply-to, --no-chain-reply-to — if this is set, each email will be sent as a reply to the previous email sent. If disabled with --no-chain-reply-to, all emails after the first will be sent as replies to the first email sent. When using that, it's recommended that the first file you give be an overview of the entire patch series. Disabled by default, but the sendemail.chainReplyTo configuration variable can be used to enable it. 🦋
  • --identity=<identity> — a configuration identity. When given, it causes values in the sendemail.<identity> subsection to take precedence over values in the sendemail section. The default identity is the value of sendemail.identity.
  • --signed-off-by-cc, --no-signed-off-by-cc — if this is set, add emails found in the Signed-off-by trailer or Cc: lines to the cc list. Default is the value of the sendemail.signedOffByCc configuration value; if that's unspecified, it defaults to --signed-off-by-cc.
  • --cc-cover, --no-cc-cover — if this is set, emails found in Cc: headers in the first patch of the series (typically the cover letter) are added to the cc list for each email set. Default is the value of the sendemail.ccCover configuration value; if that's unspecified, it defaults to --no-cc-cover.
  • --to-cover, --no-to-cover — if this is set, emails found in To: headers in the first patch of the series (typically the cover letter) are added to the to list for each email set. Default is the value of the sendemail.toCover configuration value; if that's unspecified, it defaults to --no-to-cover.
  • --suppress-cc=<category> — specify an additional category of recipients to suppress the auto-cc of:
    • author will avoid including the patch author.
    • self will avoid including the sender.
    • cc will avoid including anyone mentioned in Cc lines in the patch header, except for self (use self for that).
    • bodycc will avoid including anyone mentioned in Cc lines in the patch body (commit message), except for self (use self for that).
    • sob will avoid including anyone mentioned in the Signed-off-by trailers, except for self (use self for that).
    • misc-by will avoid including anyone mentioned in Acked-by, Reviewed-by, Tested-by and other "-by" lines in the patch body, except Signed-off-by (use sob for that).
    • cccmd will avoid running the --cc-cmd.
    • body is equivalent to sob + bodycc + misc-by.
    • all will suppress all auto cc values.

Default is the value of the sendemail.suppressCc configuration value; if that's unspecified, it defaults to self if --suppress-from is specified, as well as body if --no-signed-off-by-cc is specified.

  • --suppress-from, --no-suppress-from — if this is set, do not add the From: address to the Cc: list. Default is the value of the sendemail.suppressFrom configuration value; if that's unspecified, it defaults to --no-suppress-from.
  • --thread, --no-thread — if this is set, the In-Reply-To and References headers will be added to each email sent. Whether each mail refers to the previous email (deep threading, per git format-patch wording) or to the first email (shallow threading) is governed by --[no-]chain-reply-to.

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's unspecified, it defaults to --thread.

⚠️ It is up to you 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. No cap, this one bites people. 💀
  • --mailmap, --no-mailmap — use the mailmap file (see gitmailmap(5)) to map all addresses to their canonical real name and email address. Additional mailmap data specific to git send-email may be provided using the sendemail.mailmap.file or sendemail.mailmap.blob configuration values. Defaults to sendemail.mailmap.

✨ Administering ✨

  • --confirm=<mode> — confirm just before sending. Your options, bestie:
    • always will always confirm before sending.
    • never will never confirm before sending.
  • cc — bestie it's gonna double-check with you before sending whenever send-email has automatically slid addresses from the patch into the Cc list 💅
  • compose — it asks you before sending the very first message when you're using --compose 🫶
  • auto — this is literally just cc + compose combined, iconic behavior ✨

Default is whatever the sendemail.confirm config value says; if that's not set anywhere, it defaults to auto — unless any of the suppress options got specified, in which case it defaults to compose instead. Sneaky but true 😌

  • --dry-run — do literally everything except the one thing: actually sending the emails. Rehearsal mode, no cap 🎭
  • --format-patch, --no-format-patch — when an argument could be read either as a reference or as a file name, this picks a lane: --format-patch means "treat it as a format-patch argument", --no-format-patch means "treat it as a file name" 🗂️ By default, when that conflict happens, git send-email just fails. It does not pick for you, it is not your mom.
  • --quiet — makes git send-email less chatty. One line per email, that's the whole output. Minimalist queen 🌸
  • --validate, --no-validate — runs sanity checks on your patches. Right now "validation" means these two things:
    • It invokes the sendemail-validate hook if one exists (peep githooks(5) 👀).
    • It warns you about patches containing lines longer than 998 characters, unless a suitable transfer encoding (auto, base64, or quoted-printable) is in play — this is because of SMTP limits, as described by https://www.ietf.org/rfc/rfc5322.txt 📏

Default is the value of sendemail.validate; if that's not set, it defaults to --validate.

  • --force — send those emails even when the safety checks are actively trying to stop you. It's giving "I know better" energy 🚨

💌 Information 💌

  • --dump-aliases — instead of doing the normal thing, it dumps the shorthand alias names out of the configured alias file(s), one per line, in alphabetical order 🔤 Heads up: this only includes the alias name, not its expanded email addresses. See sendemail.aliasesFile for more about aliases.
  • --translate-aliases — instead of the normal thing, it reads from standard input and interprets each line as an email alias, translating it according to the configured alias file(s) 🧚 Then it outputs each translated name and email address to standard output, one per line. See sendemail.aliasFile for more information about aliases.

⚙️ CONFIGURATION ⚙️

Okay so literally everything below this line in this section is selectively pulled from the git-config(1) documentation. The content is the same as what's over there, fr fr:

  • sendemail.identity — a configuration identity 🪪 When you give one, it makes values in the sendemail.<identity> subsection take precedence over values in the sendemail section. The default identity is the value of sendemail.identity.
  • sendemail.smtpEncryption — see git-send-email(1) for the description. Note that this setting is not subject to the identity mechanism 👑
  • sendemail.smtpSSLCertPath — path to ca-certificates (either a directory or a single file) 📁 Set it to an empty string to disable certificate verification. That's your call bestie.
  • sendemail.smtpSSLClientCert — path to the client certificate file to present if the server asks for it 🔐 This is required when the server is set up to verify client certificates. If the corresponding private key isn't included in the file, it must be supplied using sendemail.smtpSSLClientKey or the --smtp-ssl-client-key option.
  • sendemail.smtpSSLClientKey — path to the client private key file that corresponds to the client certificate 🗝️ To avoid misconfiguration, this config must be used together with sendemail.smtpSSLClientCert or the --smtp-ssl-client-cert option. If the client key is included in the client certificate, which private key gets chosen depends on the format of the certificate. Visit https://metacpan.org/pod/IO::Socket::SSL for more details.
  • sendemail.<identity>.<config> — identity-specific versions of the sendemail.<config> parameters found below, taking precedence over those when this identity is selected, whether that's through the command-line or through sendemail.identity 💫
  • sendemail.multiEdit — if true (which is the default), a single editor instance gets spawned to edit the files you have to edit (patches when --annotate is used, and the summary when --compose is used) 📝 If false, files get edited one after the other, spawning a brand new editor each and every time. Chaotic but valid.
  • sendemail.confirm — sets the default for whether to confirm before sending. Must be one of always, never, cc, compose, or auto. See --confirm in the git-send-email(1) documentation for the meaning of these values 👀
  • sendemail.mailmap — if true, makes git-send-email(1) assume --mailmap, otherwise assume --no-mailmap. False by default.
  • sendemail.mailmap.file — the location of a git-send-email(1)-specific augmenting mailmap file 🗺️ The default mailmap and mailmap.file are loaded first. So entries in this file take precedence over entries in the default mailmap locations. See gitmailmap(5).
  • sendemail.mailmap.blob — like sendemail.mailmap.file, but the value is treated as a reference to a blob in the repository 📦 Entries in sendemail.mailmap.file take precedence over entries here. See gitmailmap(5).
  • sendemail.aliasesFile — to avoid typing out long email addresses, point this at one or more email aliases files 📮 You must also supply sendemail.aliasFileType.
  • sendemail.aliasFileType — the format of the file(s) specified in sendemail.aliasesFile. Must be one of mutt, mailrc, pine, elm, gnus, or sendmail.

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

  • Quoted aliases and quoted addresses are not supported: lines that contain a " symbol are ignored 🙈
  • Redirection to a file (/path/name) or a pipe (|command) is not supported 🚫
  • File inclusion (:include: /path/name) is not supported.
  • Warnings are printed on the standard error output for any explicitly unsupported constructs, and for any other lines that aren't recognized by the parser ⚠️
  • sendemail.annotate, sendemail.bcc, sendemail.cc, sendemail.ccCmd, sendemail.chainReplyTo, sendemail.envelopeSender, sendemail.from, sendemail.headerCmd, sendemail.signedOffByCc, sendemail.smtpPass, sendemail.suppressCc, sendemail.suppressFrom, sendemail.to, sendemail.toCmd, sendemail.smtpDomain, sendemail.smtpServer, sendemail.smtpServerPort, sendemail.smtpServerOption, sendemail.smtpUser, sendemail.imapSentFolder, sendemail.useImapOnly, sendemail.thread, sendemail.transferEncoding, sendemail.validate, sendemail.xmailer — all of these configuration variables provide a default for git-send-email(1) command-line options 💅 See its documentation for details.
  • sendemail.outlookidfix — if true, makes git-send-email(1) assume --outlook-id-fix, and if false assumes --no-outlook-id-fix. If it's not specified at all, it behaves the same way as if --outlook-id-fix were not specified 🤷‍♀️
  • sendemail.signedOffCc (deprecated) — deprecated alias for sendemail.signedOffByCc. It's giving legacy, do not use, periodt 💀
  • sendemail.smtpBatchSize — number of messages to be sent per connection, after which a relogin will happen 🔁 If the value is 0 or undefined, it sends all messages in one connection. See also the --batch-size option of git-send-email(1).
  • sendemail.smtpReloginDelay — seconds to wait before reconnecting to the smtp server ⏳ See also the --relogin-delay option of git-send-email(1).
  • sendemail.forbidSendmailVariables — to avoid common misconfiguration mistakes, git-send-email(1) will abort with a warning if any configuration options for sendmail exist 😭 Set this variable to bypass the check.

📬 EXAMPLES OF SMTP SERVERS 📬

✨ Use Gmail as the SMTP Server ✨

To use git send-email to send your patches through the Gmail SMTP server, edit ~/.gitconfig to specify your account settings:

[sendemail]
    smtpEncryption = ssl
    smtpServer = smtp.gmail.com
    smtpUser = yourname@gmail.com
    smtpServerPort = 465

Gmail does not allow using your regular password for git send-email 🚫 If you have multi-factor authentication set up on your Gmail account, you can generate an app-specific password for use with git send-email. Visit https://security.google.com/settings/security/apppasswords to create it.

Alternatively, instead of using an app-specific password, you can use OAuth2.0 authentication with Gmail 🔐 OAuth2.0 is more secure than app-specific passwords, and it works regardless of whether you have multi-factor authentication set up. OAUTHBEARER and XOAUTH2 are common mechanisms used for this type of authentication, and Gmail supports both of them 👑 As an example, if you want to use OAUTHBEARER, edit your ~/.gitconfig file and add smtpAuth = OAUTHBEARER to your account settings:

[sendemail]
    smtpEncryption = ssl
    smtpServer = smtp.gmail.com
    smtpUser = yourname@gmail.com
    smtpServerPort = 465
    smtpAuth = OAUTHBEARER

Another alternative is using a tool developed by Google known as sendgmail[1] to send emails using git send-email 🛠️

✨ Use Microsoft Outlook as the SMTP Server ✨

Unlike Gmail, Microsoft Outlook no longer supports app-specific passwords 🚫 Therefore, OAuth2.0 authentication must be used for Outlook. Also, it only supports the XOAUTH2 authentication mechanism.

Edit ~/.gitconfig to specify your account settings for Outlook and use its SMTP server with git send-email:

[sendemail]
    smtpEncryption = tls
    smtpServer = smtp.office365.com
    smtpUser = yourname@outlook.com
    smtpServerPort = 587
    smtpAuth = XOAUTH2

💌 SENDING PATCHES 💌

okay bestie, so your commits are ready to go to the mailing list?? LET'S GOOO. run these, in this order, no skipping:

$ git format-patch --cover-letter -M origin/master -o outgoing/
$ edit outgoing/0000-*
$ git send-email outgoing/*

the very first time you run it, it's gonna ask you for your credentials. type in your app-specific password or your regular password, whichever is the vibe for your setup. 💅

if you've got a credential helper configured (peep git-credential(1)), the password gets saved in the credential store so you don't have to type it again next time. iconic behaviour honestly. ✨

if you're on OAuth2.0 authentication, you need to use an access token in place of a password when prompted. there are various OAuth2.0 token generators available online, and community maintained credential helpers too:

  • git-credential-gmail[2] (cross platform, dedicated helper for authenticating Gmail accounts)
  • git-credential-outlook[2] (cross platform, dedicated helper for authenticating Microsoft Outlook accounts)
  • git-credential-yahoo[2] (cross platform, dedicated helper for authenticating Yahoo accounts)
  • git-credential-aol[2] (cross platform, dedicated helper for authenticating AOL accounts)

you can also see gitcredentials(7) for more OAuth based authentication helpers. 🫶

Proton Mail does not provide an SMTP server to send emails. if you're a paid customer of Proton Mail, you can use Proton Mail Bridge[3] — officially provided by Proton Mail — to create a local SMTP server for sending emails. and for both free and paid users, community maintained projects like git-protonmail[2] can be used. 🌸

Note: the following core Perl modules that may be installed with your distribution of Perl are required:

MIME::Base64[4], MIME::QuotedPrint[5], Net::Domain[6] and Net::SMTP[7].

These additional Perl modules are also required:

Authen::SASL[8] and Mail::Address[9].

✨ Exploiting the sendmailCmd option of git send-email ✨

apart from sending emails via an SMTP server, git send-email can also send emails through any application that supports sendmail-like commands. you can read documentation of --sendmail-cmd=<command> above for more info. this ability is so useful if you wanna use another application as an SMTP client for git send-email, or if your email provider uses proprietary APIs instead of SMTP to send emails. lowkey a superpower. 🔥

as an example, let's see how to configure msmtp[10], a popular SMTP client found in many Linux distributions. edit ~/.gitconfig to instruct git-send-email to use it for sending emails.

[sendemail]
    sendmailCmd = /usr/bin/msmtp # Change this to the path where msmtp is installed

links of a few such community maintained helpers are:

  • msmtp[10] (popular SMTP client with many features, available for Linux and macOS)
  • git-protonmail[2] (cross platform client that can send emails using the ProtonMail API)
  • git-msgraph[2] (cross platform client that can send emails using the Microsoft Graph API)

💀 CAVEATS 💀

okay bestie, sit down, we need to talk. the output from git-format-patch(1) can lead to a different commit message when applied with git-am(1). the patch that is applied may also be different from the one that was generated, or patch application may fail outright. not cute. 😭

any line that is of the form:

  • three-dashes and end-of-line, or
  • a line that begins with diff -, or
  • a line that begins with `Index: `

is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.

note that this is especially problematic for unindented diffs that occur in the commit message; the diff in the commit message might get applied along with the patch section, or the patch application machinery might trip up because the patch target doesn't apply. this could for example be caused by a diff in a Markdown code block. 🙈

the solution for this is to indent the diff or other text that could cause problems. periodt.

this loss of fidelity might be simple to notice if you're applying patches directly from a mailbox. however, changes originating from Git could be applied in bulk, in which case this would be much harder to notice. this could for example be a Linux distribution which uses patch files to apply changes on top of the commits from the upstream repositories. this goes to show that this behavior does not only impact email workflows. 👑

given these limitations, one might be tempted to use a general-purpose utility like patch(1) instead. however, patch(1) will not only look for unindented diffs (like git-am(1)) but will try to apply indented diffs as well. so yeah, pick your fighter wisely. ⭐

🌈 SEE ALSO 🌈

git-format-patch(1), git-imap-send(1), mbox(5)

🧚 GIT 🧚

Part of the git(1) suite

📝 NOTES 📝

  1. sendgmail https://github.com/google/gmail-oauth2-tools/tree/master/go/sendgmail
  2. git-credential-gmail https://github.com/AdityaGarg8/git-credential-email
  3. Proton Mail Bridge https://proton.me/mail/bridge
  4. MIME::Base64 https://metacpan.org/pod/MIME::Base64
  5. MIME::QuotedPrint https://metacpan.org/pod/MIME::QuotedPrint
  6. Net::Domain https://metacpan.org/pod/Net::Domain
  7. Net::SMTP https://metacpan.org/pod/Net::SMTP
  8. Authen::SASL https://metacpan.org/pod/Authen::SASL
  9. Mail::Address https://metacpan.org/pod/Mail::Address
  10. msmtp https://marlam.de/msmtp/

and that's a wrap on the whole page, bestie!! 💖 this lil masterpiece is from Git 2.56.0, dated 09/28/2026, and it lives at GIT-SEND-EMAIL(1). now go send some patches, you absolute icon. 🎀🦋✨

📦 where this page comes from