aboutsummaryrefslogtreecommitdiffstats
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2013-07-04send-email: provide port separately from hostnamebrian m. carlson1-2/+4
If the SMTP port is provided as part of the hostname to Net::SMTP, it passes the combined string to the SASL provider; this causes GSSAPI authentication to fail since Kerberos does not want the port information. Instead, pass the port as a separate argument as is done for SSL connections. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27Merge branch 'mt/send-email-cc-match-fix'Junio C Hamano1-2/+3
Logic used by git-send-email to suppress cc mishandled names that need RFC2047 quoting. * mt/send-email-cc-match-fix: send-email: sanitize author when writing From line send-email: add test for duplicate utf8 name
2013-06-20send-email: sanitize author when writing From lineMichael S. Tsirkin1-2/+3
sender is now sanitized, but we didn't sanitize author when checking whether From: line is needed in the message body. As a result git started writing duplicate From: lines when author matched sender and has utf8 characters. Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14Merge branch 'mt/send-email-cc-match-fix'Junio C Hamano1-8/+15
Logic git-send-email used to suppress cc mishandled names like "A U. Thor" <author@example.xz>, where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * mt/send-email-cc-match-fix: test-send-email: test for pre-sanitized self name t/send-email: test suppress-cc=self with non-ascii t/send-email: add test with quoted sender send-email: make --suppress-cc=self sanitize input t/send-email: test suppress-cc=self on cccmd send-email: fix suppress-cc=self on cccmd t/send-email.sh: add test for suppress-cc=self
2013-06-05send-email: make --suppress-cc=self sanitize inputMichael S. Tsirkin1-8/+15
--suppress-cc=self fails to filter sender address in many cases where it needs to be sanitized in some way, for example quoted: "A U. Thor" <author@example.com> To fix, make send-email sanitize both sender and the address it is compared against. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05send-email: fix suppress-cc=self on cccmdMichael S. Tsirkin1-1/+1
When cccmd is used, old-style suppress-from filter is applied by the newer suppress-cc=self isn't. Fix this up. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28send-email: remove warning about unset chainreplytoFelipe Contreras1-17/+2
Three years and a half is probably more than enough time to give users the opportunity to configure Git to do what they want. If they haven't changed the configuration by now, this warning message is not going to do anything for them anyway. This effectively reverts commit 528fb08 (prepare send-email for smoother change of --chain-reply-to default). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07send-email: make annotate configurableFelipe Contreras1-3/+4
Some people always do --annotate, lets not force them to always type that. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'rr/send-email-perl-critique'Junio C Hamano1-8/+10
Update "git send-email" for issues noticed by PerlCritic. * rr/send-email-perl-critique: send-email: use the three-arg form of open in recipients_cmd send-email: drop misleading function prototype send-email: use "return;" not "return undef;" on error codepaths
2013-03-31send-email: use the three-arg form of open in recipients_cmdRamkumar Ramachandra1-1/+1
Perlcritic does not want to see the trailing pipe in the two-args form of open(), i.e. open my $fh, "$cmd \Q$file\E |"; If $cmd were a single-token command name, it would make a lot more sense to use four-or-more-args form "open FILEHANDLE,MODE,CMD,ARGS" to avoid shell from expanding metacharacters in $file, but we do expect multi-word string in $to_cmd and $cc_cmd to be expanded by the shell, so we cannot rewrite it to open my $fh, "-|", $cmd, $file; for extra safety. At least, by using this in the three-arg form: open my $fh, "-|", "$cmd \Q$file\E"; we can silence Perlcritic, even though we do not gain much safety by doing so. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: drop misleading function prototypeRamkumar Ramachandra1-4/+6
The subroutine check_file_rev_conflict() is called from two places, both of which expects to pass a single scalar variable and see if that can be interpreted as a pathname or a revision name. It is defined with a function prototype ($) to force a scalar context while evaluating the arguments at the calling site but it does not help the current calling sites. The only effect it has is to hurt future calling sites that may want to build an argument list in an array variable and call it as check_file_rev_confict(@args). Drop the misleading prototype, as Perlcritic suggests. While at it, rename the function to avoid new call sites unaware of this change arising and add a comment clarifying what this function is for. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31send-email: use "return;" not "return undef;" on error codepathsRamkumar Ramachandra1-3/+3
All the callers of "ask", "extract_valid_address", and "validate_patch" subroutines assign the return values from them to a single scalar: $var = subr(...); and "return undef;" in these subroutine can safely be turned into a simpler "return;". Doing so will also future-proof a new caller that mistakenly does this: @foo = ask(...); if (@foo) { ... we got an answer ... } else { ... we did not ... } Note that we leave "return undef;" in validate_address on purpose, even though Perlcritic may complain. The primary "return" site of the function returns whatever is in the scalar variable $address, so it is pointless to change only the other "return undef;" to "return". The caller must be prepared to see an array with a single undef as the return value from this subroutine anyway. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-27git-send-email: use git credential to obtain passwordMichal Nazarewicz1-28/+43
If smtp_user is provided but smtp_pass is not, instead of prompting for password, make git-send-email use git credential command instead. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-14Merge branch 'nz/send-email-headers-are-case-insensitive'Junio C Hamano1-5/+5
When user spells "cc:" in lowercase in the fake "header" in the trailer part, send-email failed to pick up the addresses from there. As e-mail headers field names are case insensitive, this script should follow suit and treat "cc:" and "Cc:" the same way. * nz/send-email-headers-are-case-insensitive: git-send-email: treat field names as case-insensitively
2013-01-06git-send-email: treat field names as case-insensitivelyNickolai Zeldovich1-5/+5
Field names like To:, Cc:, etc. are case-insensitive; use a case-insensitive regexp to match them as such. Previously, git-send-email would fail to pick-up the addresses when in-body "fake" headers with different cases (e.g. lowercase "cc:") are manually inserted to the messages it was asked to send, even though the text will still show them. Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29Merge branch 'km/send-email-remove-cruft-in-address'Junio C Hamano1-18/+59
* km/send-email-remove-cruft-in-address: git-send-email: allow edit invalid email address git-send-email: ask what to do with an invalid email address git-send-email: remove invalid addresses earlier git-send-email: fix fallback code in extract_valid_address() git-send-email: remove garbage after email address
2012-11-26git-send-email: allow edit invalid email addressKrzysztof Mazur1-3/+6
In some cases the user may want to send email with "Cc:" line with email address we cannot extract. Now we allow user to extract such email address for us. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: ask what to do with an invalid email addressKrzysztof Mazur1-2/+10
We used to warn about invalid emails and just drop them. Such warnings can be unnoticed by user or noticed after sending email when we are not giving the "final sanity check [Y/n]?" Now we quit by default. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove invalid addresses earlierKrzysztof Mazur1-13/+39
Some addresses are passed twice to unique_email_list() and invalid addresses may be reported twice per send_message. Now we warn about them earlier and we also remove invalid addresses. This also removes using of undefined values for string comparison for invalid addresses in cc list processing. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26send-email: avoid questions when user has an identFelipe Contreras1-6/+1
Currently we keep getting questions even when the user has properly configured his full name and password: Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] And once a question pops up, other questions are turned on. This is annoying. The reason it's safe to avoid this question is because currently the script fails completely when the author (or committer) is not correct, so we won't even be reaching this point in the code. The scenarios, and the current situation: 1) No information at all, no fully qualified domain name fatal: empty ident name (for <felipec@nysa.(none)>) not allowed 2) Only full name fatal: unable to auto-detect email address (got 'felipec@nysa.(none)') 3) Full name + fqdm Who should the emails appear to be from? [Felipe Contreras <felipec@nysa.felipec.org>] 4) Full name + EMAIL Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] 5) User configured 6) GIT_COMMITTER 7) GIT_AUTHOR All these are the same as 4) After this patch: 1) 2) won't change: git send-email would still die 4) 5) 6) 7) will change: git send-email won't ask the user This is good, that's what we would expect, because the identity is explicit. 3) will change: git send-email won't ask the user This is bad, because we will try with an address such as 'felipec@nysa.felipec.org', which is most likely not what the user wants, but the user will get warned by default (confirm=auto), and if not, most likely the sending won't work, which the user would readily note and fix. The worst possible scenario is that such mail address does work, and the user sends an email from that address unintentionally, when in fact the user expected to correct that address in the prompt. This is a very, very, very unlikely scenario, with many dependencies: 1) No configured user.name/user.email 2) No specified $EMAIL 3) No configured sendemail.from 4) No specified --from argument 5) A fully qualified domain name 6) A full name in the geckos field 7) A sendmail configuration that allows sending from this domain name 8) confirm=never, or 8.1) confirm configuration not hitting, or 8.2) Getting the error, not being aware of it 9) The user expecting to correct this address in the prompt In a more likely scenario where 7) is not the case (can't send from nysa.felipec.org), the user will simply see the mail was not sent properly, and fix the problem. The much more likely scenario though, is where 5) is not the case (nysa.(none)), and git send-email will fail right away like it does now. So the likelihood of this affecting anybody seriously is very very slim, and the chances of this affecting somebody slightly are still very small. The vast majority, if not all, of git users won't be affected negatively, and a lot will benefit from this. Tests-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: fix fallback code in extract_valid_address()Krzysztof Mazur1-5/+5
In the fallback check, used when Email::Valid is not available, the extract_valid_address() uses $1 without checking for success of matching regex. The $1 variable may still hold the result of previous match, which is the address when email address was in '<>' or be undefined otherwise. Now if match fails undefined value is always returned to indicate error. The same value is used by Email::Valid->address() in that case. Previously 'foo@bar' address was rejected by Email::Valid and fallback, but '<foo@bar>' was rejected by Email::Valid, but accepted by fallback. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26git-send-email: remove garbage after email addressKrzysztof Mazur1-0/+4
In some cases it is useful to add additional information after the email address on the Cc: footer in a commit log, for instance: "Cc: Stable kernel <stable@vger.kernel.org> #v3.4 v3.5 v3.6" However, git-send-email refuses to pick up such an invalid address when the Email::Valid perl module is available, or just uses the whole line as the email address. In sanitize_address(), remove everything after the email address, so that the result is a valid email address that makes Email::Valid happy. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-25git-send-email: add rfc2047 quoting for "=?"Krzysztof Mazur1-1/+1
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters, but also for any possible rfc2047 in it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: introduce quote_subject()Krzysztof Mazur1-6/+19
The quote_rfc2047() always adds RFC2047 quoting. To avoid quoting ASCII subjects, before calling quote_rfc2047() subject must be tested for non-ASCII characters. This patch introduces a new quote_subject() function, which performs the test and calls quote_rfc2047 only if necessary. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsKrzysztof Mazur1-1/+2
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: use compose-encoding for SubjectKrzysztof Mazur1-4/+4
The commit "git-send-email: introduce compose-encoding" introduced the compose-encoding option to specify the introduction email encoding (--compose option), but the email Subject encoding was still hardcoded to UTF-8. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-10git-send-email: introduce compose-encodingKrzysztof Mazur1-1/+8
The introduction email (--compose option) have encoding hardcoded to UTF-8, but invoked editor may not use UTF-8 encoding. The encoding used by patches can be changed by the "8bit-encoding" option, but this option does not have effect on introduction email and equivalent for introduction email is missing. Added compose-encoding command line option and sendemail.composeencoding configuration option specify encoding of introduction email. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-14Merge branch 'sb/send-email-reconfirm-fix' into maintJunio C Hamano1-2/+4
* sb/send-email-reconfirm-fix: send-email: initial_to and initial_reply_to are both optional
2012-09-14Merge branch 'jc/send-email-reconfirm' into maintJunio C Hamano1-3/+13
* jc/send-email-reconfirm: send-email: validate & reconfirm interactive responses
2012-09-12Merge branch 'sb/send-email-reconfirm-fix'Junio C Hamano1-2/+4
* sb/send-email-reconfirm-fix: send-email: initial_to and initial_reply_to are both optional
2012-09-06send-email: initial_to and initial_reply_to are both optionalStephen Boyd1-2/+4
We may pick up additional recipients from the format-patch output files we are sending, in which case it is perfectly valid to leave the @initial_to empty when the prompt asks. We may want to start a new discussion thread without replying to anything, and it is valid to leave $initial_reply_to empty. An earlier update to avoid y@example.com stuffed in address fields did not take these two cases into account. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'jc/send-email-reconfirm'Junio C Hamano1-3/+13
Validate interactive input to "git send-email" to avoid common mistakes such as saying "y<RETURN>" to sender mail address whose prompt is given with a correctly guessed default. * jc/send-email-reconfirm: send-email: validate & reconfirm interactive responses
2012-08-14send-email: validate & reconfirm interactive responsesJunio C Hamano1-3/+13
People answer 'y' to "Who should the emails appear to be from?" and 'n' to "Message-ID to be used as In-Reply-To for the first email?" for some unknown reason. While it is possible that your local username really is "y" and you are sending the mail to your local colleagues, it is possible, and some might even say it is likely, that it is a user error. Fortunately, our interactive prompter already has input validation mechanism built-in. Enhance it so that we can optionally reconfirm and allow the user to pass an input that does not validate, and "softly" require input to the sender, in-reply-to, and recipient to contain "@" and "." in this order, which would catch most cases of mistakes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31send-email: improve RFC2047 quote parsingThomas Rast1-4/+6
The RFC2047 unquoting, used to parse email addresses in From and Cc headers, is broken in several ways: * It erroneously substitutes ' ' for '_' in *the whole* header, even outside the quoted field. [Noticed by Christoph.] * It is too liberal in its matching, and happily matches the start of one quoted chunk against the end of another, or even just something that looks like such an end. [Noticed by Junio.] * It fundamentally cannot cope with encodings that are not a superset of ASCII, nor several (incompatible) encodings in the same header. This patch fixes the first two by doing a more careful decoding of the outer quoting (e.g. "=AB" to represent an octet whose value is 0xAB). Fixing the fundamental issues is left for a future, more intrusive, patch. Noticed-by: Christoph Miebach <christoph.miebach@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-09send-email: multiedit is a boolean config optionJeff King1-1/+1
The sendemail.multiedit variable is meant to be a boolean. However, it is not marked as such in the code, which means we store its value literally. Thus in the do_edit function, perl ends up coercing it to a boolean value according to perl rules, not git rules. This works for "0", but "false", "no", or "off" will erroneously be interpreted as true. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-18Merge branch 'md/smtp-tls-hello-again'Junio C Hamano1-1/+1
* md/smtp-tls-hello-again: send-email: Honour SMTP domain when using TLS
2011-10-15send-email: Honour SMTP domain when using TLSMatthew Daley1-1/+1
git-send-email sends two SMTP EHLOs when using TLS encryption, however only the first, unencrypted EHLO uses the SMTP domain that can be optionally specified by the user (--smtp-domain). This is because the call to hello() that produces the second, encrypted EHLO does not pass the SMTP domain as an argument, and hence a default of 'localhost.localdomain' is used instead. Fix by passing in the SMTP domain in this call. Signed-off-by: Matthew Daley <mattjd@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14send-email: Fix %config_path_settings handlingCord Seele1-2/+10
cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-12Merge branch 'cs/perl-config-path-send-email'Junio C Hamano1-1/+9
* cs/perl-config-path-send-email: use new Git::config_path() for aliasesfile Add Git::config_path()
2011-10-12Merge branch 'zj/send-email-authen-sasl'Junio C Hamano1-0/+6
* zj/send-email-authen-sasl: send-email: auth plain/login fix
2011-09-30use new Git::config_path() for aliasesfileCord Seele1-1/+9
Signed-off-by: Cord Seele <cowose@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-29send-email: auth plain/login fixZbigniew Jędrzejewski-Szmek1-0/+6
git send-email was not authenticating properly when communicating over TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is e.g. the standard server setup under debian with exim4 and probably everywhere where system accounts are used. The problem (only?) exists when libauthen-sasl-cyrus-perl (Authen::SASL::Cyrus) is installed. Importing Authen::SASL::Perl makes Authen::SASL use the perl implementation which works better. The solution is based on this forum thread: http://www.perlmonks.org/?node_id=904354. This patch is tested by sending it. Without this fix, the interaction with the server failed like this: $ git send-email --smtp-encryption=tls --smtp-server=... --smtp-debug=1 change1.patch ... Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN Password: Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified 5.5.2 AUTH mechanism must be specified Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-12send-email: add option -hClemens Buchacher1-1/+4
Most other git commands print a synopsis when passed -h. Make send-email do the same. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-29git-send-email: fix missing space in error messageSylvain Rabot1-1/+1
When the command cannot make a connection to the SMTP server the error message to diagnose the broken configuration is issued. However, when an optional smtp-server-port is given and needs to be reported, the message lacked a space between "hello=<smtp-domain>" and "port=<smtp-server-port>". Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'ao/send-email-irt'Junio C Hamano1-1/+2
* ao/send-email-irt: git-send-email.perl: make initial In-Reply-To apply only to first email t9001: send-email interation with --in-reply-to and --chain-reply-to
2010-11-24Merge branch 'maint'Junio C Hamano1-1/+1
* maint: imap-send: link against libcrypto for HMAC and others git-send-email.perl: Deduplicate "to:" and "cc:" entries with names mingw: do not set errno to 0 on success
2010-11-24Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter' into maintJunio C Hamano1-0/+13
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-11-24git-send-email.perl: Deduplicate "to:" and "cc:" entries with namesJoe Perches1-1/+1
If an email address in the "to:" list is in the style "First Last <email@domain.tld>", ie: not just a bare address like "email@domain.tld", and the same named entry style exists in the "cc:" list, the current logic will not remove the entry from the "cc:" list. Add logic to better deduplicate the "cc:" list by also matching the email address with angle brackets. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12git-send-email.perl: make initial In-Reply-To apply only to first emailAntonio Ospite1-1/+2
When an initial --in-reply-to is supplied, make it apply only to the first message; --[no-]chain-reply-to setting are honored by second and subsequent messages; this is also how the git-format-patch option with the same name behaves. Moreover, when $initial_reply_to is asked to the user interactively it is asked as the "Message-ID to be used as In-Reply-To for the _first_ email", this makes the user think that the second and subsequent patches are not using it but are considered as replies to the first message or chained according to the --[no-]chain-reply setting. Look at the v2 series in the illustration to see what the new behavior ensures: (before the patch) | (after the patch) [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did... [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests [PATCH 2/2] Implementation | [PATCH 2/2] Implementation [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation This is the typical behaviour we want when we send a series with cover letter in reply to some discussion, the new patch series should appear as a separate subtree in the discussion. Also update the documentation on --in-reply-to to describe the new behavior. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-26Merge branch 'ab/send-email-perl'Junio C Hamano1-39/+35
* ab/send-email-perl: send-email: extract_valid_address use qr// regexes send-email: is_rfc2047_quoted use qr// regexes send-email: use Perl idioms in while loop send-email: make_message_id use "require" instead of "use" send-email: send_message die on $!, not $? send-email: use (?:) instead of () if no match variables are needed send-email: sanitize_address use qq["foo"], not "\"foo\"" send-email: sanitize_address use $foo, not "$foo" send-email: use \E***\Q instead of \*\*\* send-email: cleanup_compose_files doesn't need a prototype send-email: unique_email_list doesn't need a prototype send-email: file_declares_8bit_cte doesn't need a prototype send-email: get_patch_subject doesn't need a prototype send-email: use lexical filehandles during sending send-email: use lexical filehandles for $compose send-email: use lexical filehandle for opendir Conflicts: git-send-email.perl
2010-10-26Merge branch 'sb/send-email-use-to-from-input'Junio C Hamano1-8/+17
* sb/send-email-use-to-from-input: send-email: Don't leak To: headers between patches send-email: Use To: headers in patch files Conflicts: git-send-email.perl
2010-10-26Merge branch 'ab/require-perl-5.8'Junio C Hamano1-1/+2
* ab/require-perl-5.8: perl: use "use warnings" instead of -w perl: bump the required Perl version to 5.8 from 5.6.[21]
2010-10-26Merge branch 'jp/send-email-to-cmd'Junio C Hamano1-17/+34
* jp/send-email-to-cmd: git-send-email.perl: Add --to-cmd Conflicts: git-send-email.perl
2010-10-26Merge branch 'po/sendemail'Junio C Hamano1-3/+9
* po/sendemail: New send-email option smtpserveroption. Remove @smtp_host_parts variable as not used. Minor indentation fix.
2010-10-04send-email: Don't leak To: headers between patchesStephen Boyd1-8/+10
If the first patch in a series has a To: header in the file and the second patch in the series doesn't the address from the first patch will be part of the To: addresses in the second patch. Fix this by treating the to list like the cc list. Have an initial to list come from the command line, user input and config options. Then build up a to list from each patch and concatenate the two together before sending the patch. Finally, reset the list after sending each patch so the To: headers from a patch don't get used for the next one. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: extract_valid_address use qr// regexesÆvar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: is_rfc2047_quoted use qr// regexesÆvar Arnfjörð Bjarmason1-2/+2
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use Perl idioms in while loopÆvar Arnfjörð Bjarmason1-3/+2
Change `while(<$fh>) { my $c = $_' to `while(my $c = <$fh>) {', and use `chomp $c' instead of `$c =~ s/\n$//g;', the two are equivalent in this case. I've also changed the --cccmd test so that we test for the stripping of whitespace at the beginning of the lines returned from the --cccmd. I think we probably shouldn't do this, but it was there already so I haven't changed the behavior. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: make_message_id use "require" instead of "use"Ævar Arnfjörð Bjarmason1-1/+1
Change the use of Sys::Hostname from a "use" to a "require". The former happens in an implicit BEGIN block and is thus immune from the if block it's contained in, so it's always loaded. This should speed up the invocation of git-send-email by a few milliseconds. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: send_message die on $!, not $?Ævar Arnfjörð Bjarmason1-1/+1
If close fails we want to emit errno, not the return code of whatever happened to be the child process run. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use (?:) instead of () if no match variables are neededÆvar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: sanitize_address use qq["foo"], not "\"foo\""Ævar Arnfjörð Bjarmason1-1/+1
Perl provides an alternate quote syntax which can make using "" inside interpolated strings easier to read. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: sanitize_address use $foo, not "$foo"Ævar Arnfjörð Bjarmason1-1/+1
There's no reason to explicitly stringify a variable in Perl unless it's an overloaded object and you want to call overload::StrVal, otherwise it's just creating a new scalar redundantly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use \E***\Q instead of \*\*\*Ævar Arnfjörð Bjarmason1-1/+1
Change the regex introduced in a03bc5b to use the \E...\Q escape syntax instead of using backslashes. It's more readable like this, and easier to grep for. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: cleanup_compose_files doesn't need a prototypeÆvar Arnfjörð Bjarmason1-3/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: unique_email_list doesn't need a prototypeÆvar Arnfjörð Bjarmason1-2/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: file_declares_8bit_cte doesn't need a prototypeÆvar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: get_patch_subject doesn't need a prototypeÆvar Arnfjörð Bjarmason1-1/+1
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandles during sendingÆvar Arnfjörð Bjarmason1-7/+7
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandles for $composeÆvar Arnfjörð Bjarmason1-11/+11
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use lexical filehandle for opendirÆvar Arnfjörð Bjarmason1-3/+3
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter'Junio C Hamano1-0/+13
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-09-29Merge branch 'ab/send-email-catfile'Junio C Hamano1-1/+2
* ab/send-email-catfile: send-email: use catfile() to concatenate files
2010-09-29send-email: Use To: headers in patch filesStephen Boyd1-0/+7
It's a minor annoyance when you take the painstaking time to setup To: headers for each patch in a large series, and then go out to send the series with git-send-email and watch git ignore the To: headers in the patch files. Therefore, always add To: headers from a patch file to the To: headers for that message. Keep the prompt for the blanket To: header so as to not break scripts (and user expectations). This means even if a patch has a To: header, git will prompt for the To: address. Otherwise, we'll need to introduce interface breakage to either request the header for each patch missing a To: header or default the header to whatever To: address is found first (be it in a patch or from user input). Both of these options don't seem very obvious/useful. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Tested-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27perl: use "use warnings" instead of -wÆvar Arnfjörð Bjarmason1-1/+1
Change the Perl scripts to turn on lexical warnings instead of setting the global $^W variable via the -w switch. The -w sets warnings for all code that interpreter runs, while "use warnings" is lexically scoped. The former is probably not what the authors wanted. As an auxiliary benefit it's now possible to build Git with: PERL_PATH='/usr/bin/env perl' Which would previously result in failures, since "#!/usr/bin/env perl -w" doesn't work as a shebang. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27perl: bump the required Perl version to 5.8 from 5.6.[21]Ævar Arnfjörð Bjarmason1-0/+1
Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already used the three-arg form of open() which was introduced in 5.6.1, but t/t9700/test.pl explicitly depended on 5.6.2. However git-add--interactive.pl has been failing on the 5.6 line since it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open syntax: sub run_cmd_pipe { my $fh = undef; open($fh, '-|', @_) or die; return <$fh>; } Which when executed dies on "Can't use an undefined value as filehandle reference". Several of our tests also fail on 5.6 (even more when compiled with NO_PERL_MAKEMAKER=1): t2016-checkout-patch.sh t3904-stash-patch.sh t3701-add-interactive.sh t7105-reset-patch.sh t7501-commit.sh t9700-perl-git.sh Our code is bitrotting on 5.6 with no-one interested in fixing it, and pinning us to such an ancient release of Perl is keeping us from using useful features introduced in the 5.8 release. The 5.6 series is now over 10 years old, and the 5.6.2 maintenance release almost 7. 5.8 on the other hand is more than 8 years old. All the modern Unix-like operating systems have now upgraded to it or a later version, and 5.8 packages are available for old IRIX, AIX Solaris and Tru64 systems. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Tor Arntsen <tor@spacetec.no> Acked-by: Randal L. Schwartz <merlyn@stonehenge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27git-send-email.perl: Add --to-cmdJoe Perches1-17/+34
Add the ability to use a command line --to-cmd=cmd to create the list of "To:" addresses. Used a shared routine for --cc-cmd and --to-cmd. Did not use IPC::Open2, leaving that for Ævar if ever he decides to fix the other bugs he might find. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27git-send-email.perl: ensure $domain is defined before using itBrandon Casey1-1/+1
valid_fqdn() may attempt to operate on an undefined value if Net::Domain::domainname fails to determine the domain name. This causes perl to emit unpleasant warnings. So, add a check for whether $domain has been defined before using it. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-14send-email: use catfile() to concatenate filesÆvar Arnfjörð Bjarmason1-1/+2
Change send-email to use Perl's catfile() function instead of "$dir/$file". If send-email is given a $dir that ends with a / we'll end up printing a double slashed path like "dir//mtfnpy.patch". This doesn't cause any problems since Perl's IO layer will handle it, but it looks ugly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-08send-email: Refuse to send cover-letter template subjectThomas Rast1-0/+13
Every so often, someone sends out an unedited cover-letter template. Add a simple check to send-email that refuses to send if the subject contains "*** SUBJECT HERE ***", with an option --force to override. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06New send-email option smtpserveroption.Pascal Obry1-1/+7
The new command line parameter --smtp-server-option or default configuration sendemail.smtpserveroption can be used to pass specific options to the SMTP server. Update the documentation accordingly. Signed-off-by: Pascal Obry <pascal@obry.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06Remove @smtp_host_parts variable as not used.Pascal Obry1-1/+1
Signed-off-by: Pascal Obry <pascal@obry.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-06Minor indentation fix.Pascal Obry1-1/+1
Signed-off-by: Pascal Obry <pascal@obry.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27Merge branch 'tr/send-email-8bit'Junio C Hamano1-0/+60
* tr/send-email-8bit: send-email: ask about and declare 8bit mails
2010-06-18send-email: ask about and declare 8bit mailsThomas Rast1-0/+60
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>
2010-05-08Merge branch 'bg/send-email-smtpdomain'Junio C Hamano1-26/+22
* 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 Gernhardt1-10/+9
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>
2010-04-10send-email: Don't use FQDNs without a '.'Brian Gernhardt1-4/+7
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>
2010-04-10send-email: Cleanup { styleBrian Gernhardt1-12/+6
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>
2010-04-03Merge branch 'mg/maint-send-email-lazy-editor'Junio C Hamano1-1/+4
* mg/maint-send-email-lazy-editor: send-email: lazily assign editor variable
2010-04-03Merge branch 'ja/send-email-ehlo'Junio C Hamano1-3/+77
* 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 Gruber1-1/+4
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>
2010-03-14git-send-email.perl - try to give real name of the calling host to HELO/EHLOJari Aalto1-1/+67
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>
2010-03-14git-send-email.perl: add option --smtp-debugJari Aalto1-2/+7
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-14git-send-email.perl: improve error message in send_message()Jari Aalto1-1/+4
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-08send-email: add --no-cc, --no-to, and --no-bccStephen Boyd1-4/+10
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>
2009-12-26Merge branch 'jc/1.7.0-send-email-no-thread-default'Junio C Hamano1-3/+3
* 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 Hamano1-1/+3
2009-11-29prepare send-email for smoother change of --chain-reply-to defaultNanako Shiraishi1-2/+17
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>
2009-11-27send-email: automatic envelope senderFelipe Contreras1-1/+3
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>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder1-1/+2
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>
2009-10-18Merge branch 'jp/maint-send-email-fold'Junio C Hamano1-2/+4
* jp/maint-send-email-fold: git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
2009-10-09git-send-email.perl: fold multiple entry "Cc:" and multiple single line ↵Joe Perches1-2/+4
"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: http://www.ietf.org/rfc/rfc2821.txt Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-01send-email: fix mutt regex for grouped aliasesFelipe Contreras1-1/+1
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>
2009-09-25send-email: fix obscure error when encryption=tls and smtp cannot connectYakov Lerner1-1/+1
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>
2009-08-22send-email: make --no-chain-reply-to the defaultJunio C Hamano1-2/+2
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>
2009-08-05Merge branch 'maint-1.6.3' into maintJunio C Hamano1-1/+0
* 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-Lund1-1/+0
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
2009-07-25Merge branch 'jk/maint-send-email-alias-loop'Junio C Hamano1-7/+11
* jk/maint-send-email-alias-loop: send-email: detect cycles in alias expansion
2009-07-24send-email: detect cycles in alias expansionJeff King1-7/+11
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>
2009-06-18Test cccmd in t9001-send-email.sh and fix some bugsPaolo Bonzini1-2/+2
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>
2009-06-12Merge branch 'mh/maint-fix-send-email-threaded' into mh/fix-send-email-threadedJunio C Hamano1-1/+1
* 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
2009-06-12send-email: fix a typo in a commentMarkus Heidelberg1-1/+1
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-12send-email: fix threaded mails without chain-reply-toMarkus Heidelberg1-1/+2
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>
2009-06-12send-email: fix non-threaded mailsMarkus Heidelberg1-1/+2
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>
2009-06-09send-email: use UTF-8 rather than utf-8 for consistencyBrandon Casey1-2/+2
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>
2009-06-09git-send-email.perl: improve detection of MIME encoded-wordsBrandon Casey1-1/+9
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>
2009-05-31Merge branch 'mw/send-email'Junio C Hamano1-8/+12
* 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 Hamano1-0/+1
* 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. Biederman1-1/+1
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>
2009-05-13send-email: Add config option for sender addressTrent Piepho1-0/+1
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>
2009-04-22Add parsing of elm aliases to git-send-emailBill Pemberton1-0/+8
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>
2009-04-14send-email: Remove superfluous `my $editor = ...'Michael Witten1-2/+0
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>
2009-04-14send-email: 'References:' should only reference what is sentMichael Witten1-4/+10
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>
2009-04-14send-email: Handle "GIT:" rather than "GIT: " during --composeMichael Witten1-2/+2
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>
2009-04-04send-email: fix nasty bug in ask() functionJay Soffian1-2/+2
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>
2009-04-02send-email: ensure quoted addresses are rfc2047 encodedJay Soffian1-1/+2
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>
2009-04-01send-email: ask_default should apply to all emails, not just the firstJay Soffian1-2/+1
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>
2009-04-01send-email: don't attempt to prompt if tty is closedJay Soffian1-0/+3
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>
2009-03-29send-email: refactor and ensure prompting doesn't loop foreverJay Soffian1-32/+34
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>
2009-03-17Merge branch 'tr/maint-1.6.0-send-email-irt'Junio C Hamano1-1/+1
* 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/t9001-send-email.sh
2009-03-02send-email: add --confirm option and configuration settingJay Soffian1-23/+61
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>
2009-03-02send-email: respect in-reply-to regardless of threadingThomas Rast1-1/+1
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>
2009-02-23send-email: don't create temporary compose file until it is neededJay Soffian1-9/+11
Commit eed6ca7 caused a minor regression when it switched to using tempfile() to generate the temporary compose file. Since tempfile() creates the file at the time it generates the filename, zero-length temporary files are being left behind unless --compose is used (in which case the file is cleaned up). This patch fixes the regression by not calling tempfile() to generate the compose filename unless --compose is in use. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14send-email: --suppress-cc improvementsJay Soffian1-9/+19
Since 6564828 (git-send-email: Generalize auto-cc recipient mechanism., 2007-12-25) we can suppress automatic Cc generation separately for each of the possible address sources. However, --suppress-cc=sob suppressed both SOB lines and body (but not header) Cc lines, contrary to the name. Change --suppress-cc=sob to mean only SOB lines, and add separate choices 'bodycc' (body Cc lines) and 'body' (both 'sob' and 'bodycc'). The option --no-signed-off-by-cc now acts like --suppress-cc=sob, which is not backwards compatible but matches the name of the option. Also update the documentation and add a few tests. Original patch by me. Revised by Thomas Rast, who contributed the documentation and test updates. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14send-email: handle multiple Cc addresses when reading mbox messageJay Soffian1-67/+86
When git format-patch is given multiple --cc arguments, it generates a Cc header that looks like: Cc: first@example.com, second@example.com, third@example.com Before this commit, send-email was unable to handle such a message as it did not handle folded header lines, nor multiple recipients in a Cc line. This patch: - Unfolds header lines by pre-processing the header before extracting any of its fields. - Handles Cc lines with multiple recipients. - Adds use of Mail::Address if available for splitting Cc line and the "Who should the emails be sent to?" prompt", with fall back to existing split_addrs() function. - Tests the new functionality and adds two tests for detecting whether "From:" appears correctly in message body when patch author differs from patch sender. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-14send-email: allow send-email to run outside a repoJay Soffian1-2/+11
send-email is supposed to be able to run from outside a repo. This ability was broken by commits caf0c3d6 (make the message file name more specific) and 5df9fcf6 (interpret unknown files as revision lists). This commit provides a fix for both. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21send-email: futureproof split_addrs() subJunio C Hamano1-1/+1
Matt Kraai points out that calling parse_line() assuming that the caller ever passes only one argument is a bug waiting to happen, and he is right. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19Merge branch 'maint' to sync with GIT 1.6.0.6Junio C Hamano1-3/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-19git-send-email: handle email address with quoted commaWu Fengguang1-3/+8
Correctly handle email addresses containing quoted commas, e.g. "Zhu, Yi" <yi.zhu@intel.com>, "Li, Shaohua" <shaohua.li@intel.com> The commas inside the double quotes are not separators. Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-30send-email: do not reverse the command line argumentsJunio C Hamano1-1/+1
The loop picks elements from @ARGV one by one, sifts them into arguments meant for format-patch and the script itself, and pushes them to @files and @rev_list_opts arrays. Pick elements from @ARGV starting at the beginning using shift, instead of at the end using pop, as push appends them to the end of the array. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-27Merge branch 'ph/send-email'Junio C Hamano1-74/+172
* ph/send-email: git send-email: ask less questions when --compose is used. git send-email: add --annotate option git send-email: interpret unknown files as revision lists git send-email: make the message file name more specific.
2008-11-26send-email: Fix Pine address book parsingTrent Piepho1-3/+6
See: http://www.washington.edu/pine/tech-notes/low-level.html Entries with a fcc or comment field after the address weren't parsed correctly. Continuation lines, identified by leading spaces, were also not handled. Distribution lists which had ( ) around a list of addresses did not have the parenthesis removed. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git send-email: ask less questions when --compose is used.Pierre Habouzit1-73/+114
When --compose is used, we can grab the From/Subject/In-Reply-To from the edited summary, let it be so and don't ask the user silly questions. The summary templates gets quite revamped, and includes the list of patches subjects that are going to be sent with this batch. When having a body full of empty lines, the summary isn't sent. Document that in the git-send-email manpage fully. Note: It doesn't deal with To/Cc/Bcc yet. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git send-email: add --annotate optionPierre Habouzit1-2/+24
This allows to review every patch (and fix various aspects of them, or comment them) in an editor just before being sent. Combined to the fact that git send-email can now process revision lists, this makes git send-email and efficient way to review and send patches interactively. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git send-email: interpret unknown files as revision listsPierre Habouzit1-5/+42
Filter out all the arguments git-send-email doesn't like to a git format-patch command, that dumps its content to a safe directory. Barf when a file/revision conflict occurs, allow it to be overriden --[no-]format-patch. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-11git send-email: make the message file name more specific.Pierre Habouzit1-3/+1
This helps editors choosing their syntax hilighting properly. Also make the file live under the git directory. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-02Merge branch 'maint'Junio C Hamano1-2/+1
* maint: Start 1.6.0.4 cycle add instructions on how to send patches to the mailing list with Gmail Documentation/gitattributes: Add subsection header for each attribute git send-email: avoid leaking directory file descriptors. send-pack: do not send out single-level refs such as refs/stash fix overlapping memcpy in normalize_absolute_path pack-objects: avoid reading uninitalized data correct cache_entry allocation Conflicts: RelNotes
2008-11-01git send-email: avoid leaking directory file descriptors.Pierre Habouzit1-2/+1
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-01send-email: signedoffcc -> signedoffbycc, but handle bothMichael Witten1-4/+5
The documentation now mentions sendemail.signedoffbycc instead of sendemail.signedoffcc in order to match with the options --signed-off-by-cc; the code has been updated to reflect this as well, but sendemail.signedoffcc is still handled. Signed-off-by: Michael Witten <mfwitten@mit.edu> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-01Docs: send-email: Create logical groupings for --help textMichael Witten1-27/+34
The options are partitioned into more digestible groups. Signed-off-by: Michael Witten <mfwitten@mit.edu> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-01send-email: change --no-validate to boolean --[no-]validateMichael Witten1-4/+5
There is also now a configuration variable: sendemail[.<identity>].validate Signed-off-by: Michael Witten <mfwitten@mit.edu> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-01Docs: send-email usage text much sexierMichael Witten1-68/+26
All of the descriptions are aligned, shorter, better arranged, and no line is greater than 78 columns. Signed-off-by: Michael Witten <mfwitten@mit.edu> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-01Docs: send-email's usage text and man page mention same optionsMichael Witten1-4/+4
Specifically, boolean options are now listed in the form --[no-]option and both forms of documentation now consistently use --[no-]signed-off-by-cc Signed-off-by: Michael Witten <mfwitten@mit.edu> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-25Merge branch 'maint'Junio C Hamano1-1/+1
* maint: Makefile: fix shell quoting tests: propagate $(TAR) down from the toplevel Makefile index-pack.c: correctly initialize appended objects send-email: find body-encoding correctly
2008-07-25send-email: find body-encoding correctlyPeter Valdemar Mørch1-1/+1
In 8291db6 (git-send-email: add charset header if we add encoded 'From', 2007-11-16), "$1" is used from a regexp without using () to capture anything in $1. Later, when that value was used, it causes a warning about a variable being undefined, instead of using the correct value for comparison (not that it makes difference in the current code that does not do actual re-encoding). Signed-off-by: Peter Valdemar Mørch <peter@morch.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Make usage strings dash-lessStephan Beyer1-1/+1
When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-09git-send-email: Fix authenticating on some servers when using TLS.Robert Shearman1-0/+3
Send HELO again after a successful STARTTLS command to refresh the list of extensions. These may be different to what is returned over a clear connection (for example the AUTH command may be accepted over a secure connection, but not over a clear connection). Furthermore, this behaviour is recommended by RFC 2487 (http://www.ietf.org/rfc/rfc2487.txt). Signed-off-by: Robert Shearman <robertshearman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-02git-send-email: Do not attempt to STARTTLS more than onceThomas Rast1-0/+1
With the previous TLS patch, send-email would attempt to STARTTLS at the beginning of every mail, despite reusing the last connection. We simply skip further encryption checks after successful TLS initiation. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01Merge branch 'kb/send-email-fifo'Junio C Hamano1-3/+5
* kb/send-email-fifo: git-send-email: Accept fifos as well as files
2008-06-28git-send-email: prevent undefined variable warnings if no encryption is setThomas Rast1-0/+3
With the previous patch, not configuring any encryption (either on or off) would leave $smtp_encryption undefined. We simply set it to the empty string in that case. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-25git-send-email: add support for TLS via Net::SMTP::SSLThomas Rast1-5/+28
We do this by handing over the Net::SMTP instance to Net::SMTP::SSL, which avoids Net::SMTP::TLS and its weird error checking. This trick is due to Brian Evins. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-25git-send-email: Accept fifos as well as filesKevin Ballard1-3/+5
When a fifo is given, validation must be skipped because we can't read the fifo twice. Ideally git-send-email would cache the read data instead of attempting to read twice, but for now just skip validation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08git-send-email: allow whitespace in addressee listPieter de Bie1-1/+1
When interactively supplying addresses to send an email to with send-email, whitespace after the separation comma (as in 'list, jc') wasn't ignored. This meant that resolving of the alias ' jc' would fail, sending an email only to list. With this patch, the optional trailing whitespace is ignored. Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-08send-email: Allow the envelope sender to be set via configurationAsk Bjørn Hansen1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21Merge branch 'jk/maint-send-email-compose'Junio C Hamano1-2/+41
* jk/maint-send-email-compose: send-email: rfc2047-quote subject lines with non-ascii characters send-email: specify content-type of --compose body Conflicts: t/t9001-send-email.sh Due to 065096c (git-send-email.perl: Handle shell metacharacters in $EDITOR properly, 2008-05-04) which is a backward incompatible change (but it makes handling of EDITOR consistent with other parts of the system), the test script t9001 had to be adjusted. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21Merge branch 'hb/maint-send-email-quote-recipients'Junio C Hamano1-1/+1
* hb/maint-send-email-quote-recipients: Fix recipient santitization
2008-05-21Fix recipient santitizationHorst H. von Brand1-1/+1
Need to quote all special characters, not just the first one Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21send-email: rfc2047-quote subject lines with non-ascii charactersJeff King1-2/+17
We always use 'utf-8' as the encoding, since we currently have no way of getting the information from the user. This also refactors the quoting of recipient names, since both processes can share the rfc2047 quoting code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21send-email: specify content-type of --compose bodyJeff King1-0/+24
If the compose message contains non-ascii characters, then we assume it is in utf-8 and include the appropriate MIME headers. If the user has already included a MIME-Version header, then we assume they know what they are doing and don't add any headers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-14Merge branch 'bd/tests'Junio C Hamano1-1/+1
* bd/tests: Rename the test trash directory to contain spaces. Fix tests breaking when checkout path contains shell metacharacters Don't use the 'export NAME=value' in the test scripts. lib-git-svn.sh: Fix quoting issues with paths containing shell metacharacters test-lib.sh: Fix some missing path quoting Use test_set_editor in t9001-send-email.sh test-lib.sh: Add a test_set_editor function to safely set $VISUAL git-send-email.perl: Handle shell metacharacters in $EDITOR properly config.c: Escape backslashes in section names properly git-rebase.sh: Fix --merge --abort failures when path contains whitespace Conflicts: t/t9115-git-svn-dcommit-funky-renames.sh
2008-05-05git-send-email.perl: Handle shell metacharacters in $EDITOR properlyBryan Donlan1-1/+1
This fixes the git-send-perl semantics for launching an editor when $GIT_EDITOR (or friends) contains shell metacharacters to match launch_editor() in builtin-tag.c. If we use the current approach (sh -c '$0 $@' "$EDITOR" files ...), we see it fails when $EDITOR has shell metacharacters: $ sh -x -c '$0 $@' "$VISUAL" "foo" + "$FAKE_EDITOR" foo "$FAKE_EDITOR": 1: "$FAKE_EDITOR": not found Whereas builtin-tag.c will invoke sh -c "$EDITOR \"$@\"". Thus, this patch changes git-send-email.perl to use the same method as the C utilities, and additionally updates t/t9001-send-email.sh to test for this bug. Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-29git-send-email: add a new sendemail.cc configuration variableMiklos Vajna1-0/+1
Some projects prefer to always CC patches to a given mailing list. In these cases, it's handy to configure that address once. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-15send-email: Don't require to be called in a repositoryFrank Lichtenheld1-9/+11
We might not have some configuration variables available, but if the user doesn't care about that, neither should we. Still use the repository if it is available, though. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-07send-email: --no-signed-off-cc should suppress 'sob' ccJunio C Hamano1-1/+2
The logic to countermand suppression of Cc to the signers with a more explicit --signed-off-by option done in 6564828 (git-send-email: Generalize auto-cc recipient mechanism) suffers from a double-negation error. A --signed-off-cc option, when false, should actively suppress CC: to be generated out of S-o-b lines, and it should refrain from suppressing when it is true. It also fixes "(sob) Adding cc:" status output; earlier it included the line terminator LF inside '%s', which was totally bogus. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-21send-email: fix In-Reply-To regressionJay Soffian1-3/+6
Fix a regression introduced by 1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "") where if the user was prompted for an initial In-Reply-To and didn't provide one, messages would be sent out with an invalid In-Reply-To of "<>" Also add test cases for the regression and the fix. A small modification was needed to allow send-email to take its replies from stdin if the environment variable GIT_SEND_EMAIL_NOTTY is set. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-20Merge branch 'maint'Junio C Hamano1-1/+1
* maint: Clarified the meaning of git-add -u in the documentation git-clone.sh: properly configure remote even if remote's head is dangling Documentation/git-stash: document options for git stash list send-email: squelch warning due to comparing undefined $_ to ""
2008-02-20send-email: squelch warning due to comparing undefined $_ to ""Jay Soffian1-1/+1
The check to see if initial_reply_to is defined was also comparing $_ to "" for a reason I cannot ascertain (looking at the commit which made the change didn't provide enlightenment), but if $_ is undefined, perl generates a warning. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11Merge branch 'mw/send-email'Junio C Hamano1-22/+72
* mw/send-email: git-send-email: Better handling of EOF git-send-email: SIG{TERM,INT} handlers git-send-email: ssh/login style password requests
2008-02-05git-send-email: Generalize auto-cc recipient mechanism.David Brown1-7/+49
There are a few options to git-send-email to suppress the automatic generation of 'Cc' fields: --suppress-from, and --signed-off-cc. However, there are other times that git-send-email automatically includes Cc'd recipients. This is not desirable for all development environments. Add a new option --suppress-cc, which can be specified one or more times to list the categories of auto-cc fields that should be suppressed. If not specified, it defaults to values to give the same behavior as specified by --suppress-from, and --signed-off-cc. The categories are: self - patch sender. Same as --suppress-from. author - patch author. cc - cc lines mentioned in the patch. cccmd - avoid running the cccmd. sob - signed off by lines. all - all non-explicit recipients Signed-off-by: David Brown <git@davidb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05git-send-email: Better handling of EOFMichael Witten1-16/+28
Before, when the user sent the EOF control character, the prompts would be repeated on the same line as the previous prompt. Now, repeat prompts display on separate lines. Signed-off-by: Michael Witten <mfwitten@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05git-send-email: SIG{TERM,INT} handlersMichael Witten1-2/+23
A single signal handler is used for both SIGTERM and SIGINT in order to clean up after an uncouth termination of git-send-email. In particular, the handler resets the text color (this cleanup was already present), turns on tty echoing (in case termination occurrs during a masked Password prompt), and informs the user of of any temporary files created by --compose. Signed-off-by: Michael Witten <mfwitten@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05git-send-email: ssh/login style password requestsMichael Witten1-4/+21
Whilst convenient, it is most unwise to record passwords in any place but one's brain. Moreover, it is especially foolish to store them in configuration files, even with access permissions set accordingly. git-send-email has been amended, so that if it detects an smtp username without a password, it promptly prompts for the password and masks the input for privacy. Furthermore, the argument to --smtp-pass has been rendered optional. The documentation has been updated to reflect these changes. Signed-off-by: Michael Witten <mfwitten@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-21send-email, fix breakage in combination with --composeGustaf Hendeby1-1/+1
This fixes the subtile bug in git send-email that was introduced into git send-email with aa54892f5ada8282643dc7387b33261c7135d784 (send-email: detect invocation errors earlier), which caused no patches to be sent out if the --compose flag was used. Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Tested-by: Seth Falcon <seth@userprimary.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-18send-email: add no-validate optionJeff King1-3/+9
Since we are now sanity-checking the contents of patches and refusing to send ones with long lines, this knob provides a way for the user to override the new behavior (if, e.g., he knows his SMTP path will handle it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-18send-email: validate patches before sending anythingJeff King1-0/+17
We try to catch errors early so that we don't end up sending half of a broken patch series. Right now the only validation is checking that line-lengths are under the SMTP-mandated limit of 998. The validation parsing is very crude (it just checks each line length without understanding the mailbox format) but should work fine for this simple check. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-18send-email: detect invocation errors earlierJeff King1-28/+27
We never even look at the command line arguments until after we have prompted the user for some information. So running "git send-email" without arguments would prompt for "from" and "to" headers, only to then die with "No patch files specified." Instead, let's try to do as much error checking as possible before getting user input. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-22Make git send-email accept $EDITOR with argumentsGustaf Hendeby1-1/+1
Currently git send-email does not accept $EDITOR with arguments, eg, emacs -nw, when starting an editor to produce a cover letter. This patch changes this by letting the shell handle the option parsing. Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-17Merge branch 'maint'Junio C Hamano1-1/+5
* maint: git-send-email: avoid duplicate message-ids clone: correctly report http_fetch errors
2007-12-17git-send-email: avoid duplicate message-idsJeff King1-1/+5
We used to unconditionally add a message-id to the outgoing email without bothering to check if it already had one. Instead, let's use the existing one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-11send-email: do not muck with initial-reply-to when unset.Junio C Hamano1-3/+4
When not prompting, initial_reply_to can be left unset. Do not try to sanitize it and get useless warning. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-09git-send-email.perl: Really add angle brackets to In-Reply-To if necessaryMike Hommey1-2/+3
3803bcea tried to fix this, but it only adds the branckes when the given In-Reply-To begins and ends with whitespaces. It also didn't do anything to the --in-reply-to argument. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-22Authenticate only once in git-send-emailWincent Colaiuta1-1/+2
When using git-send-email with SMTP authentication sending a patch series would redundantly authenticate multiple times, once for each patch. In the worst case, this would actually prevent the series from being sent because the server would reply with a "5.5.0 Already Authenticated" status code which would derail the process. This commit teaches git-send-email to authenticate once and only once at the beginning of the series. Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-20Merge branch 'maint'Junio C Hamano1-1/+2
* maint: send-email: add transfer encoding header with content-type Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys. config: clarify compression defaults config: correct core.loosecompression documentation
2007-11-20send-email: add transfer encoding header with content-typeJeff King1-1/+2
We add the content-type header only when we have non-7bit characters from the 'From' header, so we really need to specify the encoding (in other cases, where the commit text needed a content-type, git-format-patch will already have added the encoding header). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-20send-email: Don't add To: recipients to the Cc: headerAsk Bjørn Hansen1-1/+5
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-19git-send-email: show all headers when sending mailDavid D. Kilzer1-2/+2
As a git newbie, it was confusing to set an In-Reply-To header but then not see it printed when the git-send-email command was run. This patch prints all headers that would be sent to sendmail or an SMTP server instead of only printing From, Subject, Cc, To. It also removes the now-extraneous Date header after the "Log says" line. Added test to t/t9001-send-email.sh. Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16Merge branch 'maint'Junio C Hamano1-3/+31
* maint: Update draft release notes for 1.5.3.6 Fix per-directory exclude handing for "git add" core.excludesfile clean-up Fix t9101 test failure caused by Subversion "auto-props" git-send-email: add charset header if we add encoded 'From'
2007-11-16git-send-email: add charset header if we add encoded 'From'Jeff King1-3/+31
We sometimes pick out the original rfc822 'From' header and include it in the body of the message. If the original author's name needs encoding, then we should specify that in the content-type header. If we already had a content-type header in the mail, then we may need to re-encode. The logic is there to detect this case, but it doesn't actually do the re-encoding. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09Merge branch 'maint'Junio C Hamano1-1/+1
* maint: Start preparing for 1.5.3.6 git-send-email: Change the prompt for the subject of the initial message. SubmittingPatches: improve the 'Patch:' section of the checklist instaweb: Minor cleanups and fixes for potential problems stop t1400 hiding errors in tests Makefile: add missing dependency on wt-status.h refresh_index_quietly(): express "optional" nature of index writing better Fix sed string regex escaping in module_name. Avoid a few unportable, needlessly nested "...`...". git-mailsplit: with maildirs not only process cur/, but also new/ Signed-off-by: Junio C Hamano <gitster@pobox.com>