Commit Graph

164 Commits

Author SHA1 Message Date
Junio C Hamano 64477d20d7 Merge branch 'mc/send-email-header-cmd'
"git send-email" learned "--header-cmd=<cmd>" that can inject
arbitrary e-mail header lines to the outgoing messages.

* mc/send-email-header-cmd:
  send-email: detect empty blank lines in command output
  send-email: add --header-cmd, --no-header-cmd options
  send-email: extract execute_cmd from recipients_cmd
2023-05-15 13:59:03 -07:00
Maxim Cournoyer ba92106e93 send-email: add --header-cmd, --no-header-cmd options
Sometimes, adding a header different than CC or TO is desirable; for
example, when using Debbugs, it is best to use 'X-Debbugs-Cc' headers
to keep people in CC; this is an example use case enabled by the new
'--header-cmd' option.

The header unfolding logic is extracted to a subroutine so that it can
be reused; a test is added for coverage.

Signed-off-by: Maxim Cournoyer <>
Signed-off-by: Junio C Hamano <>
2023-05-01 08:55:52 -07:00
Jouke Witteveen 839ebad442 send-email docs: Remove mention of discontinued gmail feature
Support for "less secure apps" ended May 30, 2022.

This effectively reverts 155067a (git-send-email.txt: mention less secure
app access with Gmail, 2021-01-08).

Signed-off-by: Jouke Witteveen <>
Signed-off-by: Junio C Hamano <>
2023-04-28 13:46:58 -07:00
Junio C Hamano ba4324c4e1 e-mail workflow: Message-ID is spelled with ID in both capital letters
We used to write "Message-Id:" and "Message-ID:" pretty much
interchangeably, and the header name is defined to be case
insensitive by the RFCs, but the canonical form "Message-ID:" is
used throughout the RFC documents, so let's imitate it ourselves.

Signed-off-by: Junio C Hamano <>
Reviewed-by: Elijah Newren <>
2023-04-03 08:55:43 -07:00
Sotir Danailov a2634646eb docs: git-send-email: difference between ssl and tls smtp-encryption
New explanation for the difference between these values.
It's hard to understand what they do based only on the names.
New description of used default ports.

Signed-off-by: Sotir Danailov <>
Signed-off-by: Junio C Hamano <>
2022-10-12 11:08:37 -07:00
Ævar Arnfjörð Bjarmason bac1d52cfe send-email docs: de-duplicate configuration sections
De-duplicate the discussion of "send-email" configuration, such that
the "git-config(1)" manual page becomes the source of truth, and
"git-send-email(1)" includes the relevant part.

Most commands that suffered from such duplication had diverging text
discussing the same variables, but in this case some config was also
only discussed in one or the other.

This is mostly a move-only change, the exception is a minor rewording
of changing wording like "see above" to "see linkgit:git-config[1]",
as well as a clarification about the big section of command-line
option tweaking config being discussed in git-send-email(1)'s main

Signed-off-by: Ævar Arnfjörð Bjarmason <>
Reviewed-by: Matheus Tavares <>
Signed-off-by: Junio C Hamano <>
2022-09-07 09:46:05 -07:00
Thiago Perrotta a2ce608244 send-email docs: add format-patch options
git-send-email(1) does not mention that "git format-patch" options are
accepted. Augment SYNOPSIS and DESCRIPTION to mention it.

Update git-send-email.perl USAGE to be consistent with

Signed-off-by: Thiago Perrotta <>
Signed-off-by: Junio C Hamano <>
2021-10-28 09:06:15 -07:00
Gregory Anders cd5b33fbdc git-send-email: add option to specify sendmail command
The sendemail.smtpServer configuration option and --smtp-server command
line option both support using a sendmail-like program to send emails by
specifying an absolute file path. However, this is not ideal for the
following reasons:

1. It overloads the meaning of smtpServer (now a program is being used
   for the server?)
2. It doesn't allow for non-absolute paths, arguments, or arbitrary

Requiring an absolute path is bad for portability, as the same program
may be in different locations on different systems. If a user wishes to
pass arguments to their program, they have to use the smtpServerOption
option, which is cumbersome (as it must be repeated for each option) and
doesn't adhere to normal git conventions.

Introduce a new configuration option sendemail.sendmailCmd as well as a
command line option --sendmail-cmd that can be used to specify a command
(with or without arguments) or shell expression to run to send email.
The name of this option is consistent with --to-cmd and --cc-cmd. This
invocation honors the user's $PATH so that absolute paths are not
necessary. Arbitrary shell expressions are also supported, allowing
users to do basic scripting.

Give this option a higher precedence over --smtp-server and
sendemail.smtpServer, as the new interface is more flexible. For
backward compatibility, continue to support absolute paths in
--smtp-server and sendemail.smtpServer.

Signed-off-by: Gregory Anders <>
Signed-off-by: Junio C Hamano <>
2021-05-17 07:06:13 +09:00
Junio C Hamano 788f488b33 Merge branch 'vv/send-email-with-less-secure-apps-access'
Doc update.

* vv/send-email-with-less-secure-apps-access:
  git-send-email.txt: mention less secure app access with Gmail
2021-01-15 21:48:46 -08:00
Vasyl Vavrychuk 155067ab4f git-send-email.txt: mention less secure app access with Gmail
Google may have changed Gmail security and now less secure app access
needs to be explicitly enabled if two-factor authentication is not in
place, otherwise send-email fails with:

	5.7.8 Username and Password not accepted. Learn more at

Document steps required to make this work.

Signed-off-by: Vasyl Vavrychuk <>
Signed-off-by: Junio C Hamano <>
[dl: Clean up commit message and incorporate suggestions into patch.]
Signed-off-by: Denton Liu <>
Signed-off-by: Junio C Hamano <>
2021-01-07 22:44:28 -08:00
Bradley M. Kuhn 3abd4a67d9 Documentation: stylistically normalize references to Signed-off-by:
Ted reported an old typo in the git-commit.txt and merge-options.txt.
Namely, the phrase "Signed-off-by line" was used without either a
definite nor indefinite article.

Upon examination, it seems that the documentation (including items in
Documentation/, but also option help strings) have been quite
inconsistent on usage when referring to `Signed-off-by`.

First, very few places used a definite or indefinite article with the
phrase "Signed-off-by line", but that was the initial typo that led
to this investigation.  So, normalize using either an indefinite or
definite article consistently.

The original phrasing, in Commit 3f971fc425 (Documentation updates,
2005-08-14), is "Add Signed-off-by line".  Commit 6f855371a5 (Add
--signoff, --check, and long option-names. 2005-12-09) switched to
using "Add `Signed-off-by:` line", but didn't normalize the former
commit to match.  Later commits seem to have cut and pasted from one
or the other, which is likely how the usage became so inconsistent.

Junio stated on the git mailing list in
<> a preference to leave off
the colon.  Thus, prefer `Signed-off-by` (with backticks) for the
documentation files and Signed-off-by (without backticks) for option
help strings.

Additionally, Junio argued that "trailer" is now the standard term to
refer to `Signed-off-by`, saying that "becomes plenty clear that we
are not talking about any random line in the log message".  As such,
prefer "trailer" over "line" anywhere the former word fits.

However, leave alone those few places in documentation that use
Signed-off-by to refer to the process (rather than the specific
trailer), or in places where mail headers are generally discussed in
comparison with Signed-off-by.

Reported-by: "Theodore Y. Ts'o" <>
Signed-off-by: Bradley M. Kuhn <>
Acked-by: Taylor Blau <>
Signed-off-by: Junio C Hamano <>
2020-10-20 11:57:40 -07:00
Martin Ågren 1925fe0c8a Documentation: wrap config listings in "----"
The indented lines in these example config-file listings are indented
differently by AsciiDoc and Asciidoctor.

Fix this by marking the example config-files as code listings by
wrapping them in "----". Because this gives us some extra indentation,
we can remove the one that we have been carrying explicitly. That is,
drop the first tab of indentation on each line.

With AsciiDoc, this results in identical rendering before and after this
commit. Asciidoctor now renders this the same as AsciiDoc does.

git-config.txt pretty consistently uses twelve dashes rather than the
minimum four to spell "----". Let's stick to the file-local convention

Signed-off-by: Martin Ågren <>
Signed-off-by: Junio C Hamano <>
2019-09-09 11:05:51 -07:00
Junio C Hamano 88542ef306 Merge branch 'cm/send-email-document-req-modules'
A doc update.

* cm/send-email-document-req-modules:
  send-email: update documentation of required Perl modules
2019-06-21 11:24:10 -07:00
Junio C Hamano 86d2271f06 Merge branch 'ab/send-email-transferencoding-fix'
Since "git send-email" learned to take 'auto' as the value for the
transfer-encoding, it by mistake stopped honoring the values given
to the configuration variables sendemail.transferencoding and/or
sendemail.<ident>.transferencoding.  This has been corrected to
(finally) redoing the order of setting the default, reading the
configuration and command line options.

* ab/send-email-transferencoding-fix:
  send-email: fix regression in sendemail.identity parsing
  send-email: document --no-[to|cc|bcc]
  send-email: fix broken transferEncoding tests
  send-email: remove cargo-culted multi-patch pattern in tests
  send-email: do defaults -> config -> getopt in that order
  send-email: rename the @bcclist variable for consistency
  send-email: move the read_config() function above getopts
2019-06-13 13:18:46 -07:00
Chris Mayo 9df8f734fd send-email: update documentation of required Perl modules
Improve and complete the list of required email related Perl modules,
clarifying which are core Perl modules and remove Net::SMTP::SSL.

git-send-email uses the TLS support in the Net::SMTP core module from
recent versions of Perl. Documenting the minimum version is complex
because of separate numbering for Perl (5.21.5~169), Net:SMTP (2.34)
and libnet (3.01). Version numbers from commit:
bfbfc9a953 ("send-email: Net::SMTP::starttls was introduced in v2.34",

Users of older Perl versions without Net::SMTP::SSL installed will get a
clear error message.

Signed-off-by: Chris Mayo <>
Signed-off-by: Junio C Hamano <>
2019-05-31 14:41:41 -07:00
Ævar Arnfjörð Bjarmason 3ff15040e2 send-email: fix regression in sendemail.identity parsing
Fix a regression in my recent 3494dfd3ee ("send-email: do defaults ->
config -> getopt in that order", 2019-05-09). I missed that the
$identity variable needs to be extracted from the command-line before
we do the config reading, as it determines which config variable we
should read first. See [1] for the report.

The sendemail.identity feature was added back in
34cc60ce2b ("send-email: Add support for SSL and SMTP-AUTH",
2007-09-03), there were no tests to assert that it worked properly.

So let's fix both the regression, and add some tests to assert that
this is being parsed properly. While I'm at it I'm adding a
--no-identity option to go with --[to|cc|bcc] variable, since the
semantics are similar. It's like to/cc/bcc except that unlike those we
don't support multiple identities, but we could now easily add it
support for it if anyone cares.

In just fixing the --identity command-line parsing bug I discovered
that a narrow fix to that wouldn't do. In read_config() we had a state
machine that would only set config values if they weren't set already,
and thus by proxy we wouldn't e.g. set "to" based on if
we'd seen before, with --identity=gmail.

I'd modified some of the relevant code in 3494dfd3ee, but just
reverting to that wouldn't do, since it would bring back the
regression fixed in that commit.

Refactor read_config() do what we actually mean here. We don't want to
set a given sendemail.VAR if a sendemail.$identity.VAR previously set
it. The old code was conflating this desire with the hardcoded
defaults for these variables, and as discussed in 3494dfd3ee that was
never going to work. Instead pass along the state of whether an
identity config set something before, as distinguished from the state
of the default just being false, or the default being a non-bool or
true (e.g. --transferencoding).

I'm still not happy with the test coverage here, e.g. there's nothing
testing sendemail.smtpEncryption, but I only have so much time to fix
this code.


Signed-off-by: Ævar Arnfjörð Bjarmason <>
Signed-off-by: Junio C Hamano <>
2019-05-29 10:33:39 -07:00
Ævar Arnfjörð Bjarmason 564eba4bc0 send-email: document --no-[to|cc|bcc]
These options added in f434c083a0 ("send-email: add --no-cc, --no-to,
and --no-bcc", 2010-03-07) were never documented.

Signed-off-by: Ævar Arnfjörð Bjarmason <>
Signed-off-by: Junio C Hamano <>
2019-05-19 10:12:51 +09:00
Jean-Noël Avila ba170517be doc: tidy asciidoc style
This mainly refers to enforcing indentation on additional lines of
items of lists.

Signed-off-by: Jean-Noël Avila <>
Signed-off-by: Junio C Hamano <>
2019-01-23 11:37:29 -08:00
Junio C Hamano 8ac6990b87 Merge branch 'jw/send-email-no-auth'
"git send-email" learned to disable SMTP authentication via the
"--smtp-auth=none" option, even when the smtp username is given
(which turns the authentication on by default).

* jw/send-email-no-auth:
  send-email: explicitly disable authentication
2018-11-06 15:50:20 +09:00
Joshua Watt 8dd9b3f85a send-email: explicitly disable authentication
It can be necessary to disable SMTP authentication by a mechanism other
than sendemail.smtpuser being undefined. For example, if the user has
sendemail.smtpuser set globally but wants to disable authentication
locally in one repository.

--smtp-auth and sendemail.smtpauth now understand the value 'none' which
means to disable authentication completely, even if an authentication
user is specified.

The value 'none' is lower case to avoid conflicts with any RFC 4422
authentication mechanisms.

The user may also specify the command line argument --no-smtp-auth as a
shorthand for --smtp-auth=none

Signed-off-by: Joshua Watt <>
Signed-off-by: Junio C Hamano <>
2018-10-23 13:37:14 +09:00
Rasmus Villemoes ef0cc1df90 send-email: also pick up cc addresses from -by trailers
When rerolling a patch series, including various Reviewed-by etc. that
may have come in, it is quite convenient to have git-send-email
automatically cc those people.

So pick up any *-by lines, with a new suppression category 'misc-by',
but special-case Signed-off-by, since that already has its own
suppression category. It seems natural to make 'misc-by' implied by

Based-on-patch-by: Joe Perches <>
Signed-off-by: Rasmus Villemoes <>
Signed-off-by: Junio C Hamano <>
2018-10-16 16:55:14 +09:00
Rasmus Villemoes af249bfe00 Documentation/git-send-email.txt: style fixes
For consistency, add full stops in a few places and outdent a line by
one space.

Signed-off-by: Rasmus Villemoes <>
Signed-off-by: Junio C Hamano <>
2018-10-11 15:19:30 +09:00
brian m. carlson e67a228cd8 send-email: automatically determine transfer-encoding
git send-email, when invoked without a --transfer-encoding option, sends
8bit data without a MIME version or a transfer encoding.  This has
several downsides.

First, unless the transfer encoding is specified, it defaults to 7bit,
meaning that non-ASCII data isn't allowed.  Second, if lines longer than
998 bytes are used, we will send an message that is invalid according to
RFC 5322.  The --validate option, which is the default, catches this
issue, but it isn't clear to many people how to resolve this.

To solve these issues, default the transfer encoding to "auto", so that
we explicitly specify 8bit encoding when lines don't exceed 998 bytes
and quoted-printable otherwise.  This means that we now always emit
Content-Transfer-Encoding and MIME-Version headers, so remove the
conditionals from this portion of the code.

It is unlikely that the unconditional inclusion of these two headers
will affect the deliverability of messages in anything but a positive
way, since MIME is already widespread and well understood by most email

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
2018-07-09 10:55:12 -07:00
brian m. carlson fa29f36d99 docs: correct RFC specifying email line length
The git send-email documentation specifies RFC 2821 (the SMTP RFC) as
providing line length limits, but the specification that restricts line
length to 998 octets is RFC 2822 (the email message format RFC).  Since
RFC 2822 has been obsoleted by RFC 5322, update the text to refer to RFC
5322 instead of RFC 2821.

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
2018-07-09 10:55:12 -07:00
brian m. carlson f2d06fb13f send-email: accept long lines with suitable transfer encoding
With --validate (which is the default), we warn about lines exceeding
998 characters due to the limits specified in RFC 5322.  However, if
we're using a suitable transfer encoding (quoted-printable or base64),
we're guaranteed not to have lines exceeding 76 characters, so there's
no need to fail in this case.  The auto transfer encoding handles this
specific case, so accept it as well.

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
2018-07-09 10:55:12 -07:00
brian m. carlson 7a36987fff send-email: add an auto option for transfer encoding
For most patches, using a transfer encoding of 8bit provides good
compatibility with most servers and makes it as easy as possible to view
patches.  However, there are some patches for which 8bit is not a valid
encoding: RFC 5322 specifies that a message must not have lines
exceeding 998 octets.

Add a transfer encoding value, auto, which indicates that a patch should
use 8bit where allowed and quoted-printable otherwise.  Choose
quoted-printable instead of base64, since base64-encoded plain text is
treated as suspicious by some spam filters.

Signed-off-by: brian m. carlson <>
Signed-off-by: Junio C Hamano <>
2018-07-09 10:55:12 -07:00
Robert P. J. Day de613050ef Use proper syntax for replaceables in command docs
The standard for command documentation synopses appears to be:

  [...] means optional
  <...> means replaceable
  [<...>] means both optional and replaceable

So fix a number of doc pages that use incorrect variations of the

Signed-off-by: Robert P. J. Day <>
Signed-off-by: Junio C Hamano <>
2018-05-25 17:16:47 +09:00
Nguyễn Thái Ngọc Duy 76a8788c14 doc: keep first level section header in upper case
When formatted as a man page, 1st section header is always in upper
case even if we write it otherwise. Make all 1st section headers
uppercase to keep it close to the final output.

This does affect html since case is kept there, but I still think it's
a good idea to maintain a consistent style for 1st section headers.

Some sections perhaps should become second sections instead, where
case is kept, and for better organization. I will update if anyone has
suggestions about this.

While at there I also make some header more consistent (e.g. examples
vs example) and fix a couple minor things here and there.

Signed-off-by: Nguyễn Thái Ngọc Duy <>
Signed-off-by: Junio C Hamano <>
2018-05-02 17:03:33 +09:00
Junio C Hamano cb6462fe74 Merge branch 'en/doc-typoes'

* en/doc-typoes:
  Documentation: normalize spelling of 'normalised'
  Documentation: fix several one-character-off spelling errors
2018-04-25 13:28:58 +09:00
Junio C Hamano f8fbcd6e01 Merge branch 'mn/send-email-credential-doc'
Doc update.

* mn/send-email-credential-doc:
  send-email: simplify Gmail example in the documentation
2018-04-25 13:28:57 +09:00
Elijah Newren c30d4f1b84 Documentation: fix several one-character-off spelling errors
Signed-off-by: Elijah Newren <>
Reviewed-by: Stefan Beller <>
Signed-off-by: Junio C Hamano <>
2018-04-09 14:15:02 +09:00
Michal Nazarewicz 4855f06fb3 send-email: simplify Gmail example in the documentation
There is no need for use to manually call ‘git credential’ especially
as the interface isn’t super user-friendly and a bit confusing.  ‘git
send-email’ will do that for them at the first execution and if the
password matches, it will be saved in the store.

Simplify the documentaion so it dosn’t include the ‘git credential’
invocation (which was incorrect anyway as it should use ‘approve’
instead of ‘fill’) and instead just mentions that credentials helper
must be set up.

Signed-off-by: Michał Nazarewicz <>
Signed-off-by: Junio C Hamano <>
2018-04-08 11:42:57 +09:00
Christian Ludwig d11c943c78 send-email: support separate Reply-To address
In some projects contributions from groups are only accepted from a
common group email address. But every individual may want to receive
replies to her own personal address. That's what we have 'Reply-To'
headers for in SMTP. So introduce an optional '--reply-to' command
line option.

This patch re-uses the $reply_to variable. This could break
out-of-tree patches!

Signed-off-by: Christian Ludwig <>
Signed-off-by: Junio C Hamano <>
2018-03-06 00:18:00 -08:00
Florian Klink 1ab2fd4f39 git-send-email: honor $PATH for sendmail binary
This extends git-send-email to also consider sendmail binaries in $PATH
after checking the (fixed) list of /usr/sbin and /usr/lib, and before
falling back to localhost.

Signed-off-by: Florian Klink <>
Signed-off-by: Junio C Hamano <>
2017-11-28 10:14:30 +09:00
Junio C Hamano eb37527ab0 Merge branch 'xz/send-email-batch-size'
"git send-email" learned to overcome some SMTP server limitation
that does not allow many pieces of e-mails to be sent over a single

* xz/send-email-batch-size:
  send-email: --batch-size to work around some SMTP server limit
2017-07-06 18:14:46 -07:00
xiaoqiang zhao 5453b83bdf send-email: --batch-size to work around some SMTP server limit
Some email servers (e.g. limit the number emails to be
sent per session (connection) and this will lead to a faliure when
sending many messages.

Teach send-email to disconnect after sending a number of messages
(configurable via the --batch-size=<num> option), wait for a few
seconds (configurable via the --relogin-delay=<seconds> option) and
reconnect, to work around such a limit.

Also add two configuration variables to give these options the default.


  We will use this as a band-aid for now, but in the longer term, we
  should look at and react to the SMTP error code from the server;
  Xianqiang reports that 450 and 451 are returned by problematic


Signed-off-by: xiaoqiang zhao <>
Signed-off-by: Junio C Hamano <>
2017-07-05 09:09:45 -07:00
Jonathan Tan 6489660b4b send-email: support validate hook
Currently, send-email has support for rudimentary e-mail validation.
Allow the user to add support for more validation by providing a
sendemail-validate hook.

Helped-by: Ævar Arnfjörð Bjarmason <>
Signed-off-by: Jonathan Tan <>
Signed-off-by: Junio C Hamano <>
2017-05-16 11:13:00 +09:00
Ævar Arnfjörð Bjarmason 2c7ee986c7 doc: change erroneous --[no]-whatever into --[no-]whatever
Change these two obvious typos to be in line with the rest of the
documentation, which uses the correct --[no-]whatever form.

Signed-off-by: Ævar Arnfjörð Bjarmason <>
Signed-off-by: Junio C Hamano <>
2017-03-20 10:04:57 -07:00
Junio C Hamano ce18123cec Merge branch 'mm/doc-tt'
More mark-up updates to typeset strings that are expected to
literally typed by the end user in fixed-width font.

* mm/doc-tt:
  doc: typeset HEAD and variants as literal
  CodingGuidelines: formatting HEAD in documentation
  doc: typeset long options with argument as literal
  doc: typeset '--' as literal
  doc: typeset long command-line options as literal
  doc: typeset short command-line options as literal
  Documentation/git-mv.txt: fix whitespace indentation
2016-07-13 11:24:14 -07:00
Matthieu Moy bcf9626a71 doc: typeset long command-line options as literal
Similarly to the previous commit, use backquotes instead of
forward-quotes, for long options.

This was obtained with:

  perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt

and manual tweak to remove false positive in ascii-art (o'--o'--o' to
describe rewritten history).

Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-28 08:36:45 -07:00
Junio C Hamano 94c61d25da Merge branch 'tr/doc-tt'
The documentation set has been updated so that literal commands,
configuration variables and environment variables are consistently
typeset in fixed-width font and bold in manpages.

* tr/doc-tt:
  doc: change configuration variables format
  doc: more consistency in environment variables format
  doc: change environment variables format
  doc: clearer rule about formatting literals
2016-06-27 09:56:42 -07:00
Tom Russello ae9f6311e9 doc: change configuration variables format
This change configuration variables that where in italic style
to monospace font according to the guideline. It was obtained with

	grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \
	sed -e 's/::$//' -e 's/\./\\\\./' | \
	xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt

Signed-off-by: Tom Russello <>
Signed-off-by: Erwan Mathoniere <>
Signed-off-by: Samuel Groot <>
Signed-off-by: Matthieu Moy <>
Reviewed-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2016-06-08 12:04:55 -07:00
SZEDER Gábor 1df036ea25 Documentation/git-send-email: fix typo in gmail 2FA section
Signed-off-by: SZEDER Gábor <>
Signed-off-by: Junio C Hamano <>
2016-06-01 17:23:38 -07:00
Michael Rappazzo 6640988123 Documentation: add instructions to help setup gmail 2FA
For those who use two-factor authentication with gmail, git-send-email
will not work unless it is setup with an app-specific password. The
example for setting up git-send-email for use with gmail will now
include information on generating and storing the app-specific password.

Signed-off-by: Michael Rappazzo <>
Signed-off-by: Junio C Hamano <>
2016-05-27 14:49:02 -07:00
Jacob Keller 17b7a83244 sendemail: teach git-send-email to dump alias names
Add an option "--dump-aliases" which changes the default behavior of
git-send-email. This mode will simply read the alias files configured by
sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all
configured aliases, one per line. The intended use case for this option
is the bash-completion script which will use it to autocomplete aliases
on the options which take addresses.

Add some tests for the new option using various alias file formats.

A possible future extension to the alias dump format could be done by
extending the --dump-aliases to take an optional argument defining the
format to display. This has not been done in this patch as no user of
this information has been identified.

Signed-off-by: Jacob Keller <>
Signed-off-by: Jeff King <>
2015-11-20 08:02:06 -05:00
Junio C Hamano 629ac65f68 Merge branch 'jv/send-email-selective-smtp-auth'
"git send-email" learned a new option --smtp-auth to limit the SMTP
AUTH mechanisms to be used to a subset of what the system library

* jv/send-email-selective-smtp-auth:
  send-email: provide whitelist of SMTP AUTH mechanisms
2015-08-26 15:45:31 -07:00
Jan Viktorin 0f2e68b54c send-email: provide whitelist of SMTP AUTH mechanisms
When sending an e-mail, the client and server must agree on an
authentication mechanism. Some servers (due to misconfiguration
or a bug) deny valid credentials for certain mechanisms. In this
patch, a new option --smtp-auth and configuration entry smtpAuth
are introduced. If smtp_auth is defined, it works as a whitelist
of allowed mechanisms for authentication selected from the ones
supported by the installed SASL perl library.

Signed-off-by: Jan Viktorin <>
Helped-by: Eric Sunshine <>
Signed-off-by: Junio C Hamano <>
2015-08-17 13:53:16 -07:00
Junio C Hamano 8f50e2eef7 Merge branch 'rl/send-email-aliases'
"git send-email" now performs alias-expansion on names that are
given via --cccmd, etc.

This round comes with a lot more enhanced e-mail address parser,
which makes it a bit scary, but as long as it works as designed, it
makes it wonderful ;-).

* rl/send-email-aliases:
  send-email: suppress meaningless whitespaces in from field
  send-email: allow multiple emails using --cc, --to and --bcc
  send-email: consider quote as delimiter instead of character
  send-email: reduce dependencies impact on parse_address_line
  send-email: minor code refactoring
  send-email: allow use of aliases in the From field of --compose mode
  send-email: refactor address list process
  t9001-send-email: refactor header variable fields replacement
  send-email: allow aliases in patch header and command script outputs
  t9001-send-email: move script creation in a setup test
2015-08-03 11:01:15 -07:00
Remi Lespinet b1c8a11c80 send-email: allow multiple emails using --cc, --to and --bcc
Accept a list of emails separated by commas in flags --cc, --to and
--bcc.  Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses from the header of an existing e-mail message,
which already lists them as comma-separated list, as a value to a
single parameter.

The following format can now be used:

    $ git send-email --to='Jane <>,'

Remove the limitation imposed by 79ee555b (Check and document the
options to prevent mistakes, 2006-06-21) which rejected every argument
with comma in --cc, --to and --bcc.

Signed-off-by: Mathieu Lienard--Mayor <>
Signed-off-by: Jorge Juan Garcia Garcia <>
Signed-off-by: Matthieu Moy <>
Signed-off-by: Remi Lespinet <>
Signed-off-by: Matthieu Moy <>
Signed-off-by: Junio C Hamano <>
2015-07-07 14:39:07 -07:00
Eric Sunshine 2532dd0605 send-email: implement sendmail aliases line continuation support
Logical lines in sendmail aliases files can be spread over multiple
physical lines[1]. A line beginning with whitespace is folded into the
preceding line. A line ending with '\' consumes the following line.


Signed-off-by: Eric Sunshine <>
Signed-off-by: Junio C Hamano <>
2015-06-01 15:53:11 -07:00