git-send-email passes on an 8bit mail as-is even if it does not
declare a content-type. Because the user can edit email between
format-patch and send-email, such invalid mails are unfortunately not
very hard to come by.
Make git-send-email stop and ask about the encoding to use if it
encounters any such mail. Also provide a configuration setting to
permanently configure an encoding.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The way the code stored --smtp-domain was unlike its handling of other
similar options. Bring it in line with the others by:
- Renaming $mail_domain to $smtp_domain to match the command line
option. Also move its declaration from near the top of the file to
near other option variables.
- Removing $mail_domain_default. The variable was used once and only
served to move the default away from where it gets used.
- Adding a sendemail.smtpdomain config option. smtp-domain was the
only SMTP configuration option that couldn't be set in the user's
.gitconfig.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although Net::Domain::domainname attempts to be very thorough, the
host's configuration can still refuse to give a FQDN. Check to see if
what we receive contains a dot as a basic sanity check.
Since the same condition is used twice and getting complex, let's move
it to a new function.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As Jakub Narebski pointed out on the list, Perl code usually prefers
sub func {
}
over
sub func
{
}
git-send-email.perl is somewhat inconsistent in its style, with 23
subroutines using the first style and 6 using the second. Convert the
few odd subroutines so that the code matches normal Perl style.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ja/send-email-ehlo:
git-send-email.perl - try to give real name of the calling host to HELO/EHLO
git-send-email.perl: add option --smtp-debug
git-send-email.perl: improve error message in send_message()
b4479f0 (add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR",
2009-10-30) introduced the use of "git var GIT_EDITOR" to obtain the
preferred editor program, instead of reading environment variables
themselves.
However, "git var GIT_EDITOR" run without a tty (think "cron job") would
give a fatal error "Terminal is dumb, but EDITOR unset". This is not a
problem for add-i, svn, p4 and callers of git_editor() defined in
git-sh-setup, as all of these call it just before launching the editor.
At that point, we know the caller wants to edit.
But send-email ran this near the beginning of the program, even if it is
not going to use any editor (e.g. run without --compose). Fix this by
calling the command only when we edit a file.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add new functions maildomain_net(), maildomain_mta() and
maildomain(), which return FQDN where possible for use in
send_message(). The value is passed to Net::SMTP HELO/EHLO
handshake. The domain name can also be set via new --smtp-domain
option.
The default value in Net::SMTP may not get through:
Net::SMTP=GLOB(0x267ec28)>>> EHLO localhost.localdomain
Net::SMTP=GLOB(0x267ec28)<<< 550 EHLO argument does not match calling host
whereas using the FQDN that matches the IP, the result is:
Net::SMTP=GLOB(0x15b8e80)>>> EHLO host.example.com
Net::SMTP=GLOB(0x15b8e80)<<< 250-host.example.com Hello host.example.com [192.168.1.7]
The maildomain*() code is based on ideas in Perl library
Test::Reporter by Graham Barr <gbarr@pobox.com> and Mark Overmeer
<mailtools@overmeer.net> released under the same terms as Perl
itself.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no way to override the sendemail.to, sendemail.cc, and
sendemail.bcc config settings. Add options allowing the user to tell
git to ignore the config settings and take whatever is on the command
line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place in $HOME/.gitconfig and change it easily.
[jc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.
RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked(-and-tested)-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Jeff King <peff@peff.net>
When encryption=tls and we cannot connect to the SMTP server,
git-send-email was printing an obtuse perl error:
Can't call method "command" on an undefined value
at git-send-email line 927.
This can occur when smtp host or port is misspelled, or the network
is down, and encryption has been set to tls.
Instead we expect some familiar "Cannot connect to SERVER:PORT"
message. Fix it to print normal "smtp can't connect" diagnostics.
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In http://article.gmane.org/gmane.comp.version-control.git/109790 I
threatened to announce a change to the default threading style used by
send-email to no-chain-reply-to (i.e. the second and subsequent messages
will all be replies to the first one), unless nobody objected, in 1.6.3.
Nobody objected, as far as I can dig the list archive. But when nothing
happened in 1.6.3 nor 1.6.4, nobody from the camp who complained loudly
that led to the message did not complain either.
So I am guessing that after all nobody cares about this. But 1.7.0 is a
good time to change this, and as I said in the message, I personally think
it is a good change, so here it is.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the previous code, an alias cycle like:
$ echo 'alias a b' >aliases
$ echo 'alias b a' >aliases
$ git config sendemail.aliasesfile aliases
$ git config sendemail.aliasfiletype mutt
would put send-email into an infinite loop. This patch
detects the situation and complains to the user.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For another patch series I'm working on I needed some tests
for the cc-cmd feature of git-send-email.
This patch adds 3 tests for the feature and for the possibility
to specify --suppress-cc multiple times, and fixes two bugs.
The first bug is that the --suppress-cc option for `cccmd' was
misspelled as `ccmd' in the code. The second bug, which is
actually found only with my other series, is that the argument
to the cccmd is never quoted, so the cccmd would fail with
patch file names containing a space.
A third bug I fix (in the docs) is that the bodycc argument was
actually spelled ccbody in the documentation and bash completion.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Cc: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mh/maint-fix-send-email-threaded:
doc/send-email: clarify the behavior of --in-reply-to with --no-thread
send-email: fix non-threaded mails
add a test for git-send-email for non-threaded mails
Conflicts:
git-send-email.perl
t/t9001-send-email.sh
An earlier commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) broke logic to set up threading
information for the next message by rewriting "!" to "not" without
understanding the precedence rules of the language.
Namely,
! defined $reply_to || length($reply_to) == 0
was changed to
not defined $reply_to || length($reply_to) == 0
which is
not (defined $reply_to || length($reply_to) == 0)
and different from what was intended, which is
(not defined $reply_to) || (length($reply_to) == 0)
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After commit 3e0c4ff (send-email: respect in-reply-to regardless of
threading, 2009-03-01) the variable $thread was only used for prompting
for an "In-Reply-To", but not for controlling whether the "In-Reply-To"
and "References" fields should be written into the email.
Thus these fields were always used beginning with the second mail and it
was not possible to produce non-threaded mails anymore.
However, a later commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) introduced a regression with the
side effect to make non-threaded mails possible again, but only when
--no-chain-reply-to was used.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rest of the git source has been converted to use upper-case character
encoding names to assist older platforms. The charset attribute of MIME
is defined to be case-insensitive, but older platforms may still have an
easier time dealing with upper-case rather than lower-case. So do so for
send-email too.
Update t9001 to handle the changes.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to rfc2047, an encoded word has the following form:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
charset = token
encoding = token
token = <Any CHAR except SPACE, CTLs, and especials>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = <Any printable ASCII character other than "?"
or SPACE>
And rfc822 defines CHARs and CTLs as:
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
The original code only detected rfc2047 encoded strings when the charset
was UTF-8. This patch generalizes the matching expression and breaks the
check for an rfc2047 encoded string into its own function. There's no real
functional change, since any properly rfc2047 encoded string would have
fallen through the remaining 'if' statements and been returned unchanged.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mw/send-email:
send-email: Remove superfluous `my $editor = ...'
send-email: 'References:' should only reference what is sent
send-email: Handle "GIT:" rather than "GIT: " during --compose
Docs: send-email: --smtp-server-port can take symbolic ports
Docs: send-email: Refer to CONFIGURATION section for sendemail.multiedit
Docs: send-email: Put options back into alphabetical order
It is legal and not uncommon to use quotes in a .mailrc file so
you can include a persons fullname as well as their email alias.
Handle this by using quotewords instead of split when parsing
.mailrc files.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The sender address, as specified with the '--from' command line option,
couldn't be set in the config file. So add a new config option,
'sendemail.from', which sets it. One can use 'sendemail.<identity>.from'
as well of course, which is likely the more useful case.
The sender address would default to GIT_AUTHOR_IDENT, which is usually the
right thing, but this doesn't allow switching based on the identity
selected. It's possible to switch the SMTP server and envelope sender by
using the '--identity' option, in which case one probably wants to use a
different from address as well, but this had to be manually specified.
The documentation for 'from' is also corrected somewhat. If '--from' is
specified (or the new sendemail.from option is used) then the user isn't
prompted. The default with no '--from' option (or sendemail.from option)
is GIT_AUTHOR_IDENT first then GIT_COMMITTER_IDENT, not just
GIT_COMMITTER_IDENT.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
elm stores a text file version of the aliases that is
<alias> = <comment> = <email address>
This adds the parsing of this file to git-send-email
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not only was it a repeat, but it also had no effect.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If someone responded with a negative (n|no) to the confirmation,
then the Message-ID of the discarded email is no longer used
in the References: header of subsequent emails.
Consequently, send_message() now returns 1 if the message was
sent and 0 otherwise.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should make things a little more robust in terms of user input;
before, even the program got it wrong by outputting a line with only
"GIT:", which was left in place as a header, because there would be
no following space character.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 6e18251 (send-email: refactor and ensure prompting doesn't loop
forever) introduced an ask function, which unfortunately had a nasty
bug. This caused it not to accept anything but the default reply to the
"Who should the emails appear to be from?" prompt, and nothing but
ctrl-d to the "Who should the emails be sent to?" and "Message-ID to be
used as In-Reply-To for the first email?" prompts.
This commit corrects the issues and adds a test to confirm the fix.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sanitize_address assumes that quoted addresses (e.g., "first last"
<first.last@example.com) do not need rfc2047 encoding, but this is
not always the case.
For example, various places in send-email extract addresses using
parse_address_line. parse_address_line returns the addresses already
quoted (e.g., "first last" <first.last@example.com), but not rfc2047
encoded.
This patch makes sanitize_address stricter about what needs rfc2047
encoding and adds a test demonstrating where I noticed the problem.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 6e18251 made the "Send this email?" prompt assume yes if confirm
= "inform" when it was unable to get a valid response. However, the
"yes" assumption only worked correctly for the first email. This commit
fixes the issue and confirms the fix by modifying the existing test for
the prompt to send multiple emails.
Reported by Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Attempting to prompt when the tty is closed (typically when running from
cron) is pointless and emits a warning. This patch causes ask() to
return early, squelching the warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several places in send-email prompt for input, and will do so forever
when the input is EOF. This is poor behavior when send-email is run
unattended (say from cron).
This patch refactors the prompting to an ask() function which takes a
prompt, an optional default, and an optional regex to validate the
input. The function returns on EOF, or if a default is provided and the
user simply types return, or if the input passes the validating regex
(which accepts all input by default). The ask() function gives up after
10 tries in case of invalid input.
There are four callers of the function:
1) "Who should the emails appear to be from?" which provides a default
sender. Previously the user would have to type ctrl-d to accept the
default. Now the user can just hit return, or type ctrl-d.
2) "Who should the emails be sent to?". Previously this prompt passed a
second argument ("") to $term->readline() which was ignored. I believe
the intent was to allow the user to just hit return. Now the user
can do so, or type ctrl-d.
3) "Message-ID to be used as In-Reply-To for the first email?".
Previously this prompt passed a second argument (effectively undef) to
$term->readline() which was ignored. I believe the intent was the same
as for (2), to allow the user to just hit return. Now the user can do
so, or type ctrl-d.
4) "Send this email?". Previously this prompt would loop forever until
it got a valid reply. Now it stops prompting on EOF or a valid reply. In
the case where confirm = "inform", it now defaults to "y" on EOF or the
user hitting return, otherwise an invalid reply causes send-email to
terminate.
A followup patch adds tests for the new functionality.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email violates the principle of least surprise by automatically
cc'ing additional recipients without confirming this with the user.
This patch teaches send-email a --confirm option. It takes the
following values:
--confirm=always always confirm before sending
--confirm=never never confirm before sending
--confirm=cc confirm before sending when send-email has
automatically added addresses from the patch to
the Cc list
--confirm=compose confirm before sending the first message when
using --compose. (Needed to maintain backwards
compatibility with existing behavior.)
--confirm=auto 'cc' + 'compose'
If sendemail.confirm is unconfigured, the option defaults to 'compose'
if any suppress-Cc related options have been used, otherwise it defaults
to 'auto'.
Unfortunately, it is impossible to introduce this patch such that it
helps new users without potentially annoying some existing users. We
attempt to mitigate the latter by:
* Allowing the user to set 'git config sendemail.confirm never'
* Allowing the user to say 'all' after the first prompt to not be
prompted on remaining emails during the same invocation.
* Telling the user about the 'sendemail.confirm' setting if it is
unconfigured whenever we prompt due to Cc before sending.
* Only prompting if no --suppress related options have been passed, as
using such an option is likely to indicate an experienced send-email
user.
There is a slight fib in message informing the user of the
sendemail.confirm setting and this is intentional. Setting 'auto'
differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
obviously squelches the informational message; 2) 'auto' prompts when
the Cc list has been expanded even in the presence of a --suppress
related option, where leaving sendemail.confirm unset does not. This is
intentional to keep the message simple, and to avoid adding another
sendemail.confirm value ('auto-except-suppress'?).
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email supports the --in-reply-to option even with
--no-thread. However, the code that adds the relevant mail headers
was guarded by a test for --thread.
Remove the test, so that the user's choice is respected.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
