path: root/git-send-email.perl
AgeCommit message (Collapse)Author
2010-06-27Merge branch 'tr/send-email-8bit'Junio C Hamano
* tr/send-email-8bit: send-email: ask about and declare 8bit mails
2010-06-18send-email: ask about and declare 8bit mailsThomas Rast
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 <> Signed-off-by: Junio C Hamano <>
2010-05-09Merge branch 'bg/send-email-smtpdomain'Junio C Hamano
* bg/send-email-smtpdomain: send-email: Cleanup smtp-domain and add config Document send-email --smtp-domain send-email: Don't use FQDNs without a '.' send-email: Cleanup { style
2010-04-10send-email: Cleanup smtp-domain and add configBrian Gernhardt
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 <> Signed-off-by: Junio C Hamano <>
2010-04-10send-email: Don't use FQDNs without a '.'Brian Gernhardt
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 <> Signed-off-by: Junio C Hamano <>
2010-04-10send-email: Cleanup { styleBrian Gernhardt
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 <> Signed-off-by: Junio C Hamano <>
2010-04-03Merge branch 'mg/maint-send-email-lazy-editor'Junio C Hamano
* mg/maint-send-email-lazy-editor: send-email: lazily assign editor variable
2010-04-03Merge branch 'ja/send-email-ehlo'Junio C Hamano
* 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()
2010-03-25send-email: lazily assign editor variableMichael J Gruber
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 <> Signed-off-by: Michael J Gruber <> Acked-by: Uwe Kleine-König <> Acked-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-03-14git-send-email.perl - try to give real name of the calling host to HELO/EHLOJari Aalto
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 Net::SMTP=GLOB(0x15b8e80)<<< Hello [] The maildomain*() code is based on ideas in Perl library Test::Reporter by Graham Barr <> and Mark Overmeer <> released under the same terms as Perl itself. Signed-off-by: Jari Aalto <> Signed-off-by: Junio C Hamano <>
2010-03-14git-send-email.perl: add option --smtp-debugJari Aalto
Signed-off-by: Jari Aalto <> Signed-off-by: Junio C Hamano <>
2010-03-14git-send-email.perl: improve error message in send_message()Jari Aalto
Signed-off-by: Jari Aalto <> Signed-off-by: Junio C Hamano <>
2010-03-08send-email: add --no-cc, --no-to, and --no-bccStephen Boyd
There's no way to override the,, 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 <> Signed-off-by: Junio C Hamano <>
2009-12-26Merge branch 'jc/1.7.0-send-email-no-thread-default'Junio C Hamano
* jc/1.7.0-send-email-no-thread-default: send-email: make --no-chain-reply-to the default Conflicts: git-send-email.perl
2009-11-30Merge branch 'fc/send-email-envelope'Junio C Hamano
2009-11-29prepare send-email for smoother change of --chain-reply-to defaultNanako Shiraishi
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 <> Signed-off-by: Junio C Hamano <>
2009-11-28send-email: automatic envelope senderFelipe Contreras
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 <> Signed-off-by: Junio C Hamano <>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder
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 <> Signed-off-by: Junio C Hamano <>
2009-10-19Merge branch 'jp/maint-send-email-fold'Junio C Hamano
* jp/maint-send-email-fold: git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
2009-10-10git-send-email.perl: fold multiple entry "Cc:" and multiple single line ↵Joe Perches
"RCPT TO:"s 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: Signed-off-by: Joe Perches <> Signed-off-by: Junio C Hamano <>
2009-10-01send-email: fix mutt regex for grouped aliasesFelipe Contreras
For example: alias -group friends foo Foo Bar <> Signed-off-by: Felipe Contreras <> Acked(-and-tested)-by: Eric Wong <> Signed-off-by: Jeff King <>
2009-09-25send-email: fix obscure error when encryption=tls and smtp cannot connectYakov Lerner
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 <> Signed-off-by: Shawn O. Pearce <>
2009-08-23send-email: make --no-chain-reply-to the defaultJunio C Hamano
In 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 <>
2009-08-05Merge branch 'maint-1.6.3' into maintJunio C Hamano
* maint-1.6.3: Better usage string for reflog. hg-to-git: don't import the unused popen2 module send-email: remove debug trace config: Keep inner whitespace verbatim
2009-08-04send-email: remove debug traceErik Faye-Lund
Signed-off-by: Erik Faye-Lund <>
2009-07-25Merge branch 'jk/maint-send-email-alias-loop'Junio C Hamano
* jk/maint-send-email-alias-loop: send-email: detect cycles in alias expansion
2009-07-24send-email: detect cycles in alias expansionJeff King
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 <> Signed-off-by: Junio C Hamano <>
2009-06-18Test cccmd in and fix some bugsPaolo Bonzini
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 <> Cc: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2009-06-12Merge branch 'mh/maint-fix-send-email-threaded' into mh/fix-send-email-threadedJunio C Hamano
* 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/
2009-06-12send-email: fix a typo in a commentMarkus Heidelberg
Signed-off-by: Markus Heidelberg <> Signed-off-by: Junio C Hamano <>
2009-06-12send-email: fix threaded mails without chain-reply-toMarkus Heidelberg
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 <> Signed-off-by: Junio C Hamano <>
2009-06-12send-email: fix non-threaded mailsMarkus Heidelberg
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 <> Signed-off-by: Junio C Hamano <>
2009-06-09send-email: use UTF-8 rather than utf-8 for consistencyBrandon Casey
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 <> Signed-off-by: Junio C Hamano <>
2009-06-09git-send-email.perl: improve detection of MIME encoded-wordsBrandon Casey
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 <> Signed-off-by: Junio C Hamano <>
2009-05-31Merge branch 'mw/send-email'Junio C Hamano
* 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
2009-05-23Merge branch 'tp/send-email-from-config'Junio C Hamano
* tp/send-email-from-config: send-email: Add config option for sender address
2009-05-21git-send-email: Handle quotes when parsing .mailrc filesEric W. Biederman
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 <> Signed-off-by: Junio C Hamano <>
2009-05-14send-email: Add config option for sender addressTrent Piepho
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 <> Signed-off-by: Junio C Hamano <>
2009-04-23Add parsing of elm aliases to git-send-emailBill Pemberton
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 <> Signed-off-by: Junio C Hamano <>
2009-04-14send-email: Remove superfluous `my $editor = ...'Michael Witten
Not only was it a repeat, but it also had no effect. Signed-off-by: Michael Witten <> Signed-off-by: Junio C Hamano <>
2009-04-14send-email: 'References:' should only reference what is sentMichael Witten
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 <> Signed-off-by: Junio C Hamano <>
2009-04-14send-email: Handle "GIT:" rather than "GIT: " during --composeMichael Witten
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 <> Signed-off-by: Junio C Hamano <>
2009-04-05send-email: fix nasty bug in ask() functionJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-04-02send-email: ensure quoted addresses are rfc2047 encodedJay Soffian
sanitize_address assumes that quoted addresses (e.g., "first last" < 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" <, 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 <> Signed-off-by: Junio C Hamano <>
2009-04-01send-email: ask_default should apply to all emails, not just the firstJay Soffian
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 <> Signed-off-by: Jay Soffian <> Signed-off-by: Junio C Hamano <>
2009-04-01send-email: don't attempt to prompt if tty is closedJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-03-30send-email: refactor and ensure prompting doesn't loop foreverJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-03-18Merge branch 'tr/maint-1.6.0-send-email-irt'Junio C Hamano
* tr/maint-1.6.0-send-email-irt: send-email: test --no-thread --in-reply-to combination send-email: respect in-reply-to regardless of threading Conflicts: t/
2009-03-03send-email: add --confirm option and configuration settingJay Soffian
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 <> Signed-off-by: Junio C Hamano <>
2009-03-03send-email: respect in-reply-to regardless of threadingThomas Rast
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 <> Signed-off-by: Junio C Hamano <>