summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2016-12-14i18n: send-email: mark composing message for translationLibravatar Vasco Almeida1-7/+9
When composing an e-mail, there is a message for the user whose lines begin in "GIT:" that can be marked for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark string with interpolation for translationLibravatar Vasco Almeida1-40/+47
Mark warnings, errors and other messages that are interpolated for translation. We call sprintf() before calling die() and in few other circumstances in order to replace the values on the placeholders. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark warnings and errors for translationLibravatar Vasco Almeida1-17/+17
Mark warnings, errors and other messages for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-14i18n: send-email: mark strings for translationLibravatar Vasco Almeida1-22/+32
Mark strings often displayed to the user for translation. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-11Merge branch 'jc/send-email-skip-backup'Libravatar Junio C Hamano1-0/+40
A careless invocation of "git send-email directory/" after editing 0001-change.patch with an editor often ends up sending both 0001-change.patch and its backup file, 0001-change.patch~, causing embarrassment and a minor confusion. Detect such an input and offer to skip the backup files when sending the patches out. * jc/send-email-skip-backup: send-email: detect and offer to skip backup files
2016-05-03Merge branch 'jd/send-email-to-whom'Libravatar Junio C Hamano1-2/+3
A question by "git send-email" to ask the identity of the sender has been updated. * jd/send-email-to-whom: send-email: fix grammo in the prompt that asks e-mail recipients
2016-04-25send-email: fix grammo in the prompt that asks e-mail recipientsLibravatar Junio C Hamano1-2/+3
The message, which dates back to the very original version 83b24437 made in 2005, sounds clumsy, grammatically incorrect, and is hard to understand. Reported-by: John Darrington <john@darrington.wattle.id.au> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22Merge branch 'ew/send-email-drop-data-dumper'Libravatar Junio C Hamano1-1/+0
Code clean-up. * ew/send-email-drop-data-dumper: send-email: do not load Data::Dumper
2016-04-22Merge branch 'ew/send-email-readable-message-id'Libravatar Junio C Hamano1-2/+3
"git send-email" now uses a more readable timestamps when formulating a message ID. * ew/send-email-readable-message-id: send-email: more meaningful Message-ID
2016-04-12send-email: detect and offer to skip backup filesLibravatar Junio C Hamano1-0/+40
Diligent people save output from format-patch to files, proofread and edit them and then finally send the result out. If the resulting files are sent out with "git send-email 0*", this ends up sending backup files (e.g. 0001-X.patch.backup or 0001-X.patch~) left by their editors next to the final version. Sending them with "git send-email 0*.patch" (if format-patch was run with the standard suffix) would avoid such an embarrassment, but not everybody is careful. After collecting files to be sent (and sorting them if read from a directory), notice when the file being sent out has the same name as the previous file, plus some suffix (e.g. 0001-X.patch was sent, and we are looking at 0001-X.patch.backup or 0001-X.patch~), and the suffix begins with a non-alnum (e.g. ".backup" or "~") and ask if the user really wants to send it out. Once the user skips sending such a "backup" file, remember the suffix and stop asking the same question (e.g. after skipping 0001-X.patch~, skip 0002-Y.patch~ without asking). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06send-email: do not load Data::DumperLibravatar Eric Wong1-1/+0
We never used Data::Dumper in this script. The only reference of it was always commented out and removed over a decade ago in commit 4bc87a28be020a6bf7387161c65ea3d8e4a0228b ("send-email: Change from Mail::Sendmail to Net::SMTP") Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06send-email: more meaningful Message-IDLibravatar Eric Wong1-2/+3
Using a YYYYmmddHHMMSS date representation is more meaningful to humans, especially when used for lookups on NNTP servers or linking to archive sites via Message-ID (e.g. mid.gmane.org or mid.mail-archive.com). This timestamp format more easily gives a reader of the URL itself a rough date of a linked message compared to having them calculate the seconds since the Unix epoch. Furthermore, having the MUA name in the Message-ID seems to be a rare oddity I haven't noticed outside of git-send-email. We already have an optional X-Mailer header field to advertise for us, so extending the Message-ID by 15 characters can make for unpleasant Message-ID-based URLs to archive sites. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18send-email: ignore trailing whitespace in mailrc alias fileLibravatar Jeff King1-1/+1
The regex for parsing mailrc considers everything after the second whitespace to be the email address, up to the end of the line. We have to include whitespace there, because you may have multiple space-separated addresses, each with their own internal quoting. But if there is trailing whitespace, we include that, too. This confuses quotewords() when we try to split the individual addresses, and we end up storing "undef" in our alias list. Later parts of the code then access that, generating perl warnings. Let's tweak our regex to throw away any trailing whitespace on each line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Merge branch 'ew/send-email-mutt-alias-fix' into maintLibravatar Junio C Hamano1-2/+7
"git send-email" was confused by escaped quotes stored in the alias files saved by "mutt", which has been corrected. * ew/send-email-mutt-alias-fix: git-send-email: do not double-escape quotes from mutt
2016-01-04git-send-email: do not double-escape quotes from muttLibravatar Eric Wong1-2/+7
mutt saves aliases with escaped quotes in the form of: alias dot \"Dot U. Sir\" <somebody@example.org> When we pass through our sanitize_address routine, we end up with double-escaping: To: "\\\"Dot U. Sir\\\" <somebody@example.org> Remove the escaping in mutt only for now, as I am not sure if other mailers can do this or if this is better fixed in sanitize_address. Cc: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Cc: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-21Merge branch 'jk/send-email-ssl-errors'Libravatar Junio C Hamano1-0/+7
Improve error reporting when SMTP TLS fails. * jk/send-email-ssl-errors: send-email: enable SSL level 1 debug output
2015-12-11send-email: enable SSL level 1 debug outputLibravatar John Keeping1-0/+7
If a server's certificate isn't accepted by send-email, the output is: Unable to initialize SMTP properly. Check config and use --smtp-debug. but adding --smtp-debug=1 just produces the same output since we don't get as far as talking SMTP. Turning on SSL debug at level 1 gives: DEBUG: .../IO/Socket/SSL.pm:1796: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:673: fatal SSL error: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed DEBUG: .../IO/Socket/SSL.pm:1780: IO::Socket::IP configuration failed IO::Socket::SSL defines level 1 debug as "print out errors from IO::Socket::SSL and ciphers from Net::SSLeay". In fact, it aliases Net::SSLeay::trace which is defined to guarantee silence at level 0 and only emit error messages at level 1, so let's enable it by default. The modification of warnings is needed to avoid a warning about: Name "IO::Socket::SSL::DEBUG" used only once: possible typo Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-04Merge branch 'jk/send-email-complete-aliases'Libravatar Junio C Hamano1-0/+15
Teach send-email to dump mail aliases, so that we can do tab completion on the command line. * jk/send-email-complete-aliases: completion: add support for completing email aliases sendemail: teach git-send-email to dump alias names
2015-12-01Merge branch 'jk/send-email-ca-path'Libravatar Jeff King1-2/+1
Use a safer behavior when we hit errors verifying remote certificates. * jk/send-email-ca-path: send-email: die if CA path doesn't exist
2015-11-24send-email: die if CA path doesn't existLibravatar John Keeping1-2/+1
If the CA path isn't found it's most likely to indicate a misconfiguration, in which case accepting any certificate is unlikely to be the correct thing to do. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20send-email: expand path in sendemail.smtpsslcertpath configLibravatar John Keeping1-1/+1
As it says in the name, the SSL certificate path is a path so treat it as one and support tilde-expansion. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20sendemail: teach git-send-email to dump alias namesLibravatar Jacob Keller1-0/+15
Add an option "--dump-aliases" which changes the default behavior of git-send-email. This mode will simply read the alias files configured by sendemail.aliasesfile and sendemail.aliasfiletype and dump a list of all configured aliases, one per line. The intended use case for this option is the bash-completion script which will use it to autocomplete aliases on the options which take addresses. Add some tests for the new option using various alias file formats. A possible future extension to the alias dump format could be done by extending the --dump-aliases to take an optional argument defining the format to display. This has not been done in this patch as no user of this information has been identified. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2015-11-05Merge branch 'sa/send-email-smtp-batch-data-limit' into maintLibravatar Junio C Hamano1-1/+5
When "git send-email" wanted to talk over Net::SMTP::SSL, Net::Cmd::datasend() did not like to be fed too many bytes at the same time and failed to send messages. Send the payload one line at a time to work around the problem. * sa/send-email-smtp-batch-data-limit: git-send-email.perl: Fixed sending of many/huge changes/patches
2015-10-15Merge branch 'sa/send-email-smtp-batch-data-limit'Libravatar Junio C Hamano1-1/+5
When "git send-email" wanted to talk over Net::SMTP::SSL, Net::Cmd::datasend() did not like to be fed too many bytes at the same time and failed to send messages. Send the payload one line at a time to work around the problem. * sa/send-email-smtp-batch-data-limit: git-send-email.perl: Fixed sending of many/huge changes/patches
2015-09-30git-send-email.perl: Fixed sending of many/huge changes/patchesLibravatar Stefan Agner1-1/+5
Sometimes sending huge patches/commits fail with [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Running the command with --smtp-debug=1 yields to Net::SMTP::SSL: Net::Cmd::datasend(): unexpected EOF on command channel: at /usr/lib/git-core/git-send-email line 1320. [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1320. Stefan described it in his mail like this: It seems to me that there is a size limit, after cutting down the patch to ~16K, sending started to work. I cut it twice, once by removing lines from the head and once from the bottom, in both cases at the size of around 16K I could send the patch. See also original report: http://permalink.gmane.org/gmane.comp.version-control.git/274569 Reported-by: Juston Li <juston.h.li@gmail.com> Tested-by: Markos Chandras <hwoarang@gentoo.org> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-21Merge branch 'bn/send-email-smtp-auth-error-message-fix'Libravatar Junio C Hamano1-1/+1
Fix a minor regression brought in to "git send-email" by a recent addition of the "--smtp-auth" option. * bn/send-email-smtp-auth-error-message-fix: send-email: fix uninitialized var warning for $smtp_auth
2015-09-21send-email: fix uninitialized var warning for $smtp_authLibravatar Brian Norris1-1/+1
On the latest version of git-send-email, I see this error just before running SMTP auth (I didn't provide any --smtp-auth= parameter): Use of uninitialized value $smtp_auth in pattern match (m//) at \ /home/briannorris/git/git/git-send-email.perl line 1139. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-26Merge branch 'jv/send-email-selective-smtp-auth'Libravatar Junio C Hamano1-1/+25
"git send-email" learned a new option --smtp-auth to limit the SMTP AUTH mechanisms to be used to a subset of what the system library supports. * jv/send-email-selective-smtp-auth: send-email: provide whitelist of SMTP AUTH mechanisms
2015-08-17send-email: provide whitelist of SMTP AUTH mechanismsLibravatar Jan Viktorin1-1/+25
When sending an e-mail, the client and server must agree on an authentication mechanism. Some servers (due to misconfiguration or a bug) deny valid credentials for certain mechanisms. In this patch, a new option --smtp-auth and configuration entry smtpAuth are introduced. If smtp_auth is defined, it works as a whitelist of allowed mechanisms for authentication selected from the ones supported by the installed SASL perl library. Signed-off-by: Jan Viktorin <viktorin@rehivetech.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'rl/send-email-aliases'Libravatar Junio C Hamano1-28/+22
"git send-email" now performs alias-expansion on names that are given via --cccmd, etc. This round comes with a lot more enhanced e-mail address parser, which makes it a bit scary, but as long as it works as designed, it makes it wonderful ;-). * rl/send-email-aliases: send-email: suppress meaningless whitespaces in from field send-email: allow multiple emails using --cc, --to and --bcc send-email: consider quote as delimiter instead of character send-email: reduce dependencies impact on parse_address_line send-email: minor code refactoring send-email: allow use of aliases in the From field of --compose mode send-email: refactor address list process t9001-send-email: refactor header variable fields replacement send-email: allow aliases in patch header and command script outputs t9001-send-email: move script creation in a setup test
2015-07-07send-email: suppress meaningless whitespaces in from fieldLibravatar Remi Lespinet1-0/+1
Remove leading and trailing whitespaces in from field before interepreting it to improve consistency with other options. The split_addrs function already take care of trailing and leading whitespaces for to, cc and bcc fields. The from option now: - has the same behavior when passing arguments like " jdoe@example.com ", "\t jdoe@example.com " or "jdoe@example.com". - interprets aliases in string containing leading and trailing whitespaces such as " alias" or "alias\t" like other options. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: allow multiple emails using --cc, --to and --bccLibravatar Remi Lespinet1-15/+2
Accept a list of emails separated by commas in flags --cc, --to and --bcc. Multiple addresses can already be given by using these options multiple times, but it is more convenient to allow cutting-and-pasting a list of addresses from the header of an existing e-mail message, which already lists them as comma-separated list, as a value to a single parameter. The following format can now be used: $ git send-email --to='Jane <jdoe@example.com>, mike@example.com' Remove the limitation imposed by 79ee555b (Check and document the options to prevent mistakes, 2006-06-21) which rejected every argument with comma in --cc, --to and --bcc. Signed-off-by: Mathieu Lienard--Mayor <Mathieu.Lienard--Mayor@ensimag.imag.fr> Signed-off-by: Jorge Juan Garcia Garcia <Jorge-Juan.Garcia-Garcia@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: consider quote as delimiter instead of characterLibravatar Remi Lespinet1-2/+4
Do not consider quote inside a recipient name as character when they are not escaped. This interprets: "Jane" "Doe" <jdoe@example.com> as: "Jane Doe" <jdoe@example.com> instead of: "Jane\" \"Doe" <jdoe@example.com> Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07send-email: reduce dependencies impact on parse_address_lineLibravatar Remi Lespinet1-1/+1
parse_address_line had not the same behavior whether the user had Mail::Address or not. Teach parse_address_line to behave like Mail::Address. When the user input is correct, this implementation behaves exactly like Mail::Address except when there are quotes inside the name: "Jane Do"e <jdoe@example.com> In this case the result of parse_address_line is: With M::A : "Jane Do" e <jdoe@example.com> Without : "Jane Do e" <jdoe@example.com> When the user input is not correct, the behavior is also mostly the same. Unlike Mail::Address, this doesn't parse groups and recursive commentaries. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: minor code refactoringLibravatar Remi Lespinet1-3/+3
Group expressions in a single if statement. This avoid checking multiple time if the variable $sender is defined. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: allow use of aliases in the From field of --compose modeLibravatar Remi Lespinet1-2/+2
Aliases were expanded before considering the From field of the --compose option. This is inconsistent with other fields (To, Cc, ...) which already support aliases. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: refactor address list processLibravatar Remi Lespinet1-10/+12
Simplify code by creating a function which transform a list of strings containing email addresses (separated by commas, comporting aliases) into a clean list of valid email addresses. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30send-email: allow aliases in patch header and command script outputsLibravatar Remi Lespinet1-0/+2
Interpret aliases in: - Header fields of patches generated by git format-patch (using --to, --cc, --add-header for example) or manually modified. Example of fields in header: To: alias1 Cc: alias2 Cc: alias3 - Outputs of command scripts specified by --cc-cmd and --to-cmd. Example of script: #!/bin/sh echo alias1 echo alias2 Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: further warn about unsupported sendmail aliases featuresLibravatar Eric Sunshine1-0/+4
The sendmail aliases parser diagnoses unsupported features and unrecognized lines. For completeness, also warn about unsupported redirection to "/path/name" and "|command", as well as ":include:". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: implement sendmail aliases line continuation supportLibravatar Eric Sunshine1-3/+7
Logical lines in sendmail aliases files can be spread over multiple physical lines[1]. A line beginning with whitespace is folded into the preceding line. A line ending with '\' consumes the following line. [1]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5 Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: simplify sendmail aliases comment and blank line recognizerLibravatar Eric Sunshine1-1/+1
Replace unnecessarily complex regular expression for recognizing comment and blank lines in sendmail aliases with idiomatic expressions which can be easily understood at a glance. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: refactor sendmail aliases parserLibravatar Eric Sunshine1-14/+24
The sendmail aliases parser inlined into %parse_alias is already uncomfortably large and is expected to grow as additional functionality is implemented, so extract it to improve manageability. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: fix style: cuddle 'elsif' and 'else' with closing braceLibravatar Eric Sunshine1-12/+5
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: drop noise comments which merely repeat what code saysLibravatar Eric Sunshine1-5/+0
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01send-email: visually distinguish sendmail aliases parser warningsLibravatar Eric Sunshine1-3/+3
Although emitted to stderr, warnings from the sendmail aliases parser are not visually distinguished as such, and thus can easily be overlooked in the normal noisy send-email output. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-27send-email: add sendmail email aliases formatLibravatar Allen Hubbe1-0/+25
Teach send-email to read aliases in the sendmail aliases format, i.e. <alias>: <address|alias>[, <address|alias>...] Examples: alice: Alice W Land <awol@example.com> bob: Robert Bobbyton <bob@example.com> # this is a comment # this is also a comment chloe: chloe@example.com abgroup: alice, bob bcgrp: bob, chloe, Other <o@example.com> - Quoted aliases and quoted addresses are not supported. - Line continuations are not supported. Warnings are printed for explicitly unsupported constructs, and any other lines that are not matched by the parser. Signed-off-by: Allen Hubbe <allenbh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-03Merge branch 'km/send-email-getopt-long-workarounds'Libravatar Junio C Hamano1-0/+10
Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support "--no-" prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * km/send-email-getopt-long-workarounds: git-send-email.perl: support no- prefix with older GetOptions
2015-02-25Merge branch 'jc/send-email-sensible-encoding'Libravatar Junio C Hamano1-0/+1
"git send-email" used to accept a mistaken "y" (or "yes") as an answer to "What encoding do you want to use [UTF-8]? " without questioning. Now it asks for confirmation when the answer looks too short to be a valid encoding name. * jc/send-email-sensible-encoding: send-email: ask confirmation if given encoding name is very short
2015-02-16git-send-email.perl: support no- prefix with older GetOptionsLibravatar Kyle J. McKay1-0/+10
Only Perl version 5.8.0 or later is required, but that comes with an older Getopt::Long (2.32) that does not support the 'no-' prefix. Support for that was added in Getopt::Long version 2.33. Since the help only mentions the 'no-' prefix and not the 'no' prefix, add explicit support for the 'no-' prefix to support older GetOptions versions. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-13send-email: ask confirmation if given encoding name is very shortLibravatar Junio C Hamano1-0/+1
Sometimes people respond "y<ENTER>" (or "yes<ENTER>") when asked this question: Which 8bit encoding should I declare [UTF-8]? We already have a mechanism to avoid accepting a mistyped e-mail address (we ask to confirm when the given address lacks "@" in it); reuse it to trigger the same confirmation when given a very short answer. As a typical charset name is probably at least 4 chars or longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would prevent such a mistake. Signed-off-by: Junio C Hamano <gitster@pobox.com>