summaryrefslogtreecommitdiff
path: root/git-send-email.perl
AgeCommit message (Collapse)AuthorFilesLines
2021-07-22Merge branch 'ab/send-email-optim'Libravatar Junio C Hamano1-60/+114
"git send-email" optimization. * ab/send-email-optim: perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd() send-email: move trivial config handling to Perl perl: lazily load some common Git.pm setup code send-email: lazily load modules for a big speedup send-email: get rid of indirect object syntax send-email: use function syntax instead of barewords send-email: lazily shell out to "git var" send-email: lazily load config for a big speedup send-email: copy "config_regxp" into git-send-email.perl send-email: refactor sendemail.smtpencryption config parsing send-email: remove non-working support for "sendemail.smtpssl" send-email tests: test for boolean variables without a value send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=true
2021-06-14Merge branch 'ga/send-email-sendmail-cmd'Libravatar Junio C Hamano1-7/+27
"git send-email" learned the "--sendmail-cmd" command line option and the "sendemail.sendmailCmd" configuration variable, which is a more sensible approach than the current way of repurposing the "smtp-server" that is meant to name the server to instead name the command to talk to the server. * ga/send-email-sendmail-cmd: git-send-email: add option to specify sendmail command
2021-05-28perl: nano-optimize by replacing Cwd::cwd() with Cwd::getcwd()Libravatar Ævar Arnfjörð Bjarmason1-1/+1
It has been pointed out[1] that cwd() invokes "pwd(1)" while getcwd() is a Perl-native XS function. For what we're using these for we can use getcwd(). The performance difference is miniscule, we're saving on the order of a millisecond or so, see [2] below for the benchmark. I don't think this matters in practice for optimizing git-send-email or perl execution (unlike the patches leading up to this one). But let's do it regardless of that, if only so we don't have to think about this as a low-hanging fruit anymore. 1. https://lore.kernel.org/git/20210512180517.GA11354@dcvr/ 2. $ perl -MBenchmark=:all -MCwd -wE 'cmpthese(10000, { getcwd => sub { getcwd }, cwd => sub { cwd }, pwd => sub { system "pwd >/dev/null" }})' (warning: too few iterations for a reliable count) Rate pwd cwd getcwd pwd 982/s -- -48% -100% cwd 1890/s 92% -- -100% getcwd 10000000000000000000/s 1018000000000000000% 529000000000000064% - Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: move trivial config handling to PerlLibravatar Ævar Arnfjörð Bjarmason1-8/+21
Optimize the startup time of git-send-email by using an amended config_regexp() function to retrieve the list of config keys and values we're interested in. For boolean keys we can handle the [true|false] case ourselves, and the "--get" case didn't need any parsing. Let's leave "--path" and other "--bool" cases to "git config". I'm not bothering with the "undef" or "" case (true and false, respectively), let's just punt on those and others and have "git config --type=bool" handle it. The "grep { defined } @values" here covers a rather subtle case. For list values such as sendemail.to it is possible as with any other config key to provide a plain "-c sendemail.to", i.e. to set the key as a boolean true. In that case the Git::config() API will return an empty string, but this new parser will correctly return "undef". However, that means we can end up with "undef" in the middle of a list. E.g. for sendemail.smtpserveroption in conjuction with sendemail.smtpserver as a path this would have produce a warning. For most of the other keys we'd behave the same despite the subtle change in the value, e.g. sendemail.to would behave the same because Mail::Address->parse() happens to return an empty list if fed "undef". For the boolean values we were already prepared to handle these variables being initialized as undef anyway. This brings the runtime of "git send-email" from ~60-~70ms to a very steady ~40ms on my test box. We now run just one "git config" invocation on startup instead of 8, the exact number will differ based on the local sendemail.* config. I happen to have 8 of those set. This brings the runtime of t9001-send-email.sh from ~13s down to ~12s for me. The change there is less impressive as many of those tests set various config values, and we're also getting to the point of diminishing returns for optimizing "git send-email" itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: lazily load modules for a big speedupLibravatar Ævar Arnfjörð Bjarmason1-32/+39
Optimize the time git-send-email takes to do even the simplest of things (such as serving up "-h") from around ~150ms to ~80ms-~90ms by lazily loading the modules it requires. Before this change Devel::TraceUse would report 99/97 used modules under NO_GETTEXT=[|Y], respectively. Now it's 52/37. It now takes ~15s to run t9001-send-email.sh, down from ~20s. Changing File::Spec::Functions::{catdir,catfile} to invoking class methods on File::Spec itself is idiomatic. See [1] for a more elaborate explanation, the resulting code behaves the same way, just without the now-pointless function wrapper. 1. http://lore.kernel.org/git/8735u8mmj9.fsf@evledraar.gmail.com Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: get rid of indirect object syntaxLibravatar Ævar Arnfjörð Bjarmason1-3/+3
Change indirect object syntax such as "new X ARGS" to "X->new(ARGS)". This allows perl to see what "new" is at compile-time without having loaded Term::ReadLine. This doesn't matter now, but will in a subsequent commit when we start lazily loading it. Let's do the same for the adjacent "FakeTerm" package for consistency, even though we're not going to conditionally load it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: use function syntax instead of barewordsLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change calls like "__ 'foo'" to "__('foo')" so the Perl compiler doesn't have to guess that "__" is a function. This makes the code more readable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: lazily shell out to "git var"Libravatar Ævar Arnfjörð Bjarmason1-5/+15
Optimize git-send-email by only shelling out to "git var" if we need to. This is easily done by re-inventing our own small version of perl's Memoize module. I suppose I could just use Memoize itself, but in a subsequent patch I'll be micro-optimizing send-email's use of dependencies. Using Memoize is a measly extra 5-10 milliseconds, but as we'll see that'll end up mattering for us in the end. This brings the runtime of a plain "send-email" from around ~160-170ms to ~140m-150ms. The runtime of the tests is around the same, or around ~20s. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: lazily load config for a big speedupLibravatar Ævar Arnfjörð Bjarmason1-9/+26
Reduce the time it takes git-send-email to get to even the most trivial of tasks (such as serving up its "-h" output) by first listing config keys that exist, and only then only call e.g. "git config --bool" on them if they do. Over a lot of runs this speeds the time to "-h" up for me from ~250ms to ~150ms, and the runtime of t9001-send-email.sh goes from ~25s to ~20s. This introduces a race condition where we'll do the "wrong" thing if a config key were to be inserted between us discovering the list and calling read_config(), i.e. we won't know about the racily added key. In theory this is a change in behavior, in practice it doesn't matter. The config_regexp() function being changed here was added in dd84e528a34 (git-send-email: die if sendmail.* config is set, 2020-07-23) for use by git-send-email. So we can change its odd return value in the case where no values are found by "git config". The difference in the *.pm code would matter if it was invoked in scalar context, but now it no longer is. Arguably this caching belongs in Git.pm itself, but in lieu of modifying it for all its callers let's only do this for "git send-email". The other big potential win would be "git svn", but unlike "git send-email" it doesn't check tens of config variables one at a time at startup (in my brief testing it doesn't check any). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: copy "config_regxp" into git-send-email.perlLibravatar Ævar Arnfjörð Bjarmason1-1/+19
The config_regexp() function was added in dd84e528a3 (git-send-email: die if sendmail.* config is set, 2020-07-23) for use in git-send-email, and it's the only in-tree user of it. However, the consensus is that Git.pm is a public interface, so even though it's a recently added function we can't change it. So let's copy over a minimal version of it to git-send-email.perl itself. In a subsequent commit it'll be changed further for our own use. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: refactor sendemail.smtpencryption config parsingLibravatar Ævar Arnfjörð Bjarmason1-8/+1
With the removal of the support for sendemail.smtpssl in the preceding commit the parsing of sendemail.smtpencryption is no longer special, and can by moved to %config_settings. This gets us rid of an unconditional call to Git::config(), which as we'll see in subsequent commits matters for startup performance. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email: remove non-working support for "sendemail.smtpssl"Libravatar Ævar Arnfjörð Bjarmason1-5/+1
Remove the already dead code to support "sendemail.smtpssl" by finally removing the dead code supporting the configuration option. In f6bebd121ac (git-send-email: add support for TLS via Net::SMTP::SSL, 2008-06-25) the --smtp-ssl command-line option was documented as deprecated, later in 65180c66186 (List send-email config options in config.txt., 2009-07-22) the "sendemail.smtpssl" configuration option was also documented as such. Then in in 3ff15040e22 (send-email: fix regression in sendemail.identity parsing, 2019-05-17) I unintentionally removed support for it by introducing a bug in read_config(). As can be seen from the diff context we've already returned unless $enc i defined, so it's not possible for us to reach the "elsif" branch here. This code was therefore already dead since Git v2.23.0. So let's just remove it. We were already 11 years into a stated deprecation period of this variable when 3ff15040e22 landed, now it's around 13. Since it hasn't worked anyway for around 2 years it looks like we can safely remove it. The --smtp-ssl option is still deprecated, if someone cares they can follow-up and remove that too, but unlike the config option that one could still be in use in the wild. I'm just removing this code that's provably unused already. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-28send-email tests: support GIT_TEST_PERL_FATAL_WARNINGS=trueLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Add support for the "GIT_TEST_PERL_FATAL_WARNINGS=true" test mode to "send-email". This was added to e.g. git-svn in 5338ed2b26 (perl: check for perl warnings while running tests, 2020-10-21), but not "send-email". Let's rectify that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-27Merge branch 'ab/send-email-inline-hooks-path'Libravatar Junio C Hamano1-1/+2
Code simplification. * ab/send-email-inline-hooks-path: send-email: move "hooks_path" invocation to git-send-email.perl send-email: don't needlessly abs_path() the core.hooksPath
2021-05-27send-email: move "hooks_path" invocation to git-send-email.perlLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Move the newly added "hooks_path" API in Git.pm to its only user in git-send-email.perl. This was added in c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23), meaning that it hasn't yet made it into a non-rc release of git. The consensus with Git.pm is that we need to be considerate of out-of-tree users who treat it as a public documented interface. We should therefore be less willing to add new functionality to it, least we be stuck supporting it after our own uses for it disappear. In this case the git-send-email.perl hook invocation will probably be replaced by a future "git hook run" command, and in the commit preceding this one the "hooks_path" become nothing but a trivial wrapper for "rev-parse --git-path hooks" anyway (with no Cwd::abs_path() call), so let's just inline this command in git-send-email.perl itself. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25send-email: fix missing error message regressionLibravatar Ævar Arnfjörð Bjarmason1-1/+11
Fix a regression with the "the editor exited uncleanly, aborting everything" error message going missing after my d21616c0394 (git-send-email: refactor duplicate $? checks into a function, 2021-04-06). I introduced a $msg variable, but did not actually use it. This caused us to miss the optional error message supplied by the "do_edit" codepath. Fix that, and add tests to check that this works. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-17git-send-email: add option to specify sendmail commandLibravatar Gregory Anders1-7/+27
The sendemail.smtpServer configuration option and --smtp-server command line option both support using a sendmail-like program to send emails by specifying an absolute file path. However, this is not ideal for the following reasons: 1. It overloads the meaning of smtpServer (now a program is being used for the server?) 2. It doesn't allow for non-absolute paths, arguments, or arbitrary scripting Requiring an absolute path is bad for portability, as the same program may be in different locations on different systems. If a user wishes to pass arguments to their program, they have to use the smtpServerOption option, which is cumbersome (as it must be repeated for each option) and doesn't adhere to normal git conventions. Introduce a new configuration option sendemail.sendmailCmd as well as a command line option --sendmail-cmd that can be used to specify a command (with or without arguments) or shell expression to run to send email. The name of this option is consistent with --to-cmd and --cc-cmd. This invocation honors the user's $PATH so that absolute paths are not necessary. Arbitrary shell expressions are also supported, allowing users to do basic scripting. Give this option a higher precedence over --smtp-server and sendemail.smtpServer, as the new interface is more flexible. For backward compatibility, continue to support absolute paths in --smtp-server and sendemail.smtpServer. Signed-off-by: Gregory Anders <greg@gpanders.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-06git-send-email: improve --validate error outputLibravatar Ævar Arnfjörð Bjarmason1-6/+6
Improve the output we emit on --validate error to: * Say "FILE:LINE" instead of "FILE: LINE", to match "grep -n", compiler error messages etc. * Don't say "patch contains a" after just mentioning the filename, just leave it at "FILE:LINE: is longer than[...]. The "contains a" sounded like we were talking about the file in general, when we're actually checking it line-by-line. * Don't just say "rejected by sendemail-validate hook", but combine that with the system_or_msg() output to say what exit code the hook died with. I had an aborted attempt to make the line length checker note all lines that were longer than the limit. I didn't think that was worth the effort, but I've left in the testing change to check that we die as soon as we spot the first long line. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-06git-send-email: refactor duplicate $? checks into a functionLibravatar Ævar Arnfjörð Bjarmason1-17/+28
Refactor the duplicate checking of $? into a function. There's an outstanding series[1] wanting to add a third use of system() in this file, let's not copy this boilerplate anymore when that happens. 1. http://lore.kernel.org/git/87y2esg22j.fsf@evledraar.gmail.com Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-02git-send-email: replace "map" in void context with "for"Libravatar Ævar Arnfjörð Bjarmason1-2/+2
While using "map" instead of "for" or "map" instead of "grep" and vice-versa makes for interesting trivia questions when interviewing Perl programmers, it doesn't make for very readable code. Let's refactor this loop initially added in 8fd5bb7f44b (git send-email: add --annotate option, 2008-11-11) to be a for-loop instead. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-23git-send-email: Respect core.hooksPath settingLibravatar Robert Foss1-1/+1
get-send-email currently makes the assumption that the 'sendemail-validate' hook exists inside of the repository. Since the introduction of 'core.hooksPath' configuration option in 867ad08a261 (hooks: allow customizing where the hook directory is, 2016-05-04), this is no longer true. Instead of assuming a hardcoded repo relative path, query git for the actual path of the hooks directory. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-23git-send-email: die if sendmail.* config is setLibravatar Drew DeVault1-0/+8
I've seen several people mis-configure git send-email on their first attempt because they set the sendmail.* config options - not sendemail.*. This patch detects this mistake and bails out with a friendly warning. Signed-off-by: Drew DeVault <sir@cmpwn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-01send-email: restore --in-reply-to superseding behaviorLibravatar Rafael Aquini1-2/+6
git send-email --in-reply-to= fails to override In-Reply-To email headers, if they're present in the output of format-patch, even when explicitly told to do so by the option --no-thread, which breaks the contract of the command line switch option, per its man page. " --in-reply-to=<identifier> Make the first mail (or all the mails with --no-thread) appear as a reply to the given Message-Id, which avoids breaking threads to provide a new patch series. " This patch fixes the aformentioned issue, by bringing --in-reply-to's old overriding behavior back. The test was donated by Carlo Marcelo Arenas Belón. Signed-off-by: Rafael Aquini <aquini@redhat.com> Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in code commentsLibravatar Elijah Newren1-1/+1
Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13Merge branch 'ab/send-email-transferencoding-fix'Libravatar Junio C Hamano1-89/+116
Since "git send-email" learned to take 'auto' as the value for the transfer-encoding, it by mistake stopped honoring the values given to the configuration variables sendemail.transferencoding and/or sendemail.<ident>.transferencoding. This has been corrected to (finally) redoing the order of setting the default, reading the configuration and command line options. * ab/send-email-transferencoding-fix: send-email: fix regression in sendemail.identity parsing send-email: document --no-[to|cc|bcc] send-email: fix broken transferEncoding tests send-email: remove cargo-culted multi-patch pattern in tests send-email: do defaults -> config -> getopt in that order send-email: rename the @bcclist variable for consistency send-email: move the read_config() function above getopts
2019-05-29send-email: fix regression in sendemail.identity parsingLibravatar Ævar Arnfjörð Bjarmason1-19/+40
Fix a regression in my recent 3494dfd3ee ("send-email: do defaults -> config -> getopt in that order", 2019-05-09). I missed that the $identity variable needs to be extracted from the command-line before we do the config reading, as it determines which config variable we should read first. See [1] for the report. The sendemail.identity feature was added back in 34cc60ce2b ("send-email: Add support for SSL and SMTP-AUTH", 2007-09-03), there were no tests to assert that it worked properly. So let's fix both the regression, and add some tests to assert that this is being parsed properly. While I'm at it I'm adding a --no-identity option to go with --[to|cc|bcc] variable, since the semantics are similar. It's like to/cc/bcc except that unlike those we don't support multiple identities, but we could now easily add it support for it if anyone cares. In just fixing the --identity command-line parsing bug I discovered that a narrow fix to that wouldn't do. In read_config() we had a state machine that would only set config values if they weren't set already, and thus by proxy we wouldn't e.g. set "to" based on sendemail.to if we'd seen sendemail.gmail.to before, with --identity=gmail. I'd modified some of the relevant code in 3494dfd3ee, but just reverting to that wouldn't do, since it would bring back the regression fixed in that commit. Refactor read_config() do what we actually mean here. We don't want to set a given sendemail.VAR if a sendemail.$identity.VAR previously set it. The old code was conflating this desire with the hardcoded defaults for these variables, and as discussed in 3494dfd3ee that was never going to work. Instead pass along the state of whether an identity config set something before, as distinguished from the state of the default just being false, or the default being a non-bool or true (e.g. --transferencoding). I'm still not happy with the test coverage here, e.g. there's nothing testing sendemail.smtpEncryption, but I only have so much time to fix this code. 1. https://public-inbox.org/git/5cddeb61.1c69fb81.47ed4.e648@mx.google.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: do defaults -> config -> getopt in that orderLibravatar Ævar Arnfjörð Bjarmason1-42/+49
Change the git-send-email command-line argument parsing and config reading code to parse those two in the right order. I.e. first we set our hardcoded defaults, then we read our config, and finally we read the command-line, with later sets overriding earlier sets. This fixes a bug introduced in e67a228cd8 ("send-email: automatically determine transfer-encoding", 2018-07-08). That change broke the reading of sendmail.transferencoding because it wasn't careful to update the code to parse them in the previous "defaults -> getopt -> config" order. But as we can see from the history for this file doing it this way was never what we actually wanted, it's just something we grew organically as of 5483c71d7a ("git-send-email: make options easier to configure.", 2007-06-27) and have been dealing with the fallout since, e.g. in 463b0ea22b ("send-email: Fix %config_path_settings handling", 2011-10-14). As can be seen in this change the only place where we actually want to do something clever is with the to/cc/bcc variables, where setting them on the command-line (or using --no-{to,cc,bcc}) should clear out values we grab from the config. All the rest are things where the command-line should simply override the config values, and by reading the config first the config code doesn't need all this "let's not set it, if it was on the command-line" special-casing, as [1] shows we'd otherwise need to care about the difference between whether something was a default or present in config to fix the bug in e67a228cd8. 1. https://public-inbox.org/git/20190508105607.178244-2-gitster@pobox.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: rename the @bcclist variable for consistencyLibravatar Ævar Arnfjörð Bjarmason1-5/+5
The "to" and "cc" variables are named @initial_{to,cc}, let's rename this one to match them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13send-email: move the read_config() function above getoptsLibravatar Ævar Arnfjörð Bjarmason1-49/+48
This is in preparation for a later change where we'll read the config first before parsing command-line options. As the move detection will show no lines (except one line of comment) is changed here, just moved around. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25Merge branch 'bs/sendemail-tighten-anything-by'Libravatar Junio C Hamano1-1/+1
The recently added feature to add addresses that are on anything-by: trailers in 'git send-email' was found to be way too eager and considered nonsense strings as if they can be legitimate beginning of *-by: trailer. This has been tightened. * bs/sendemail-tighten-anything-by: send-email: don't cc *-by lines with '-' prefix
2019-04-25Merge branch 'bc/send-email-qp-cr'Libravatar Junio C Hamano1-1/+1
"git send-email" has been taught to use quoted-printable when the payload contains carriage-return. The use of the mechanism is in line with the design originally added the codepath that chooses QP when the payload has overly long lines. * bc/send-email-qp-cr: send-email: default to quoted-printable when CR is present
2019-04-14send-email: default to quoted-printable when CR is presentLibravatar brian m. carlson1-1/+1
In 7a36987fff ("send-email: add an auto option for transfer encoding", 2018-07-08), git send-email learned how to automatically determine the transfer encoding for a patch. However, the only criterion considered was the length of the lines. Another case we need to consider is that of carriage returns. Because emails have CRLF endings when canonicalized, we don't want to write raw carriage returns into a patch, lest they be stripped off as an artifact of the transport. Ensure that we choose quoted-printable encoding if the patch we're sending contains carriage returns. Note that we are guaranteed to always correctly encode carriage returns when writing quoted-printable since we explicitly specify the line ending as "\n", forcing MIME::QuotedPrint to encode our carriage return as "=0D". Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-04send-email: don't cc *-by lines with '-' prefixLibravatar Baruch Siach1-1/+1
Since commit ef0cc1df90f6b ("send-email: also pick up cc addresses from -by trailers") in git version 2.20, git send-email adds to cc list addresses from all *-by lines. As a side effect a line with '-Signed-off-by' is now also added to cc. This makes send-email pick lines from patches that remove patch files from the git repo. This is common in the Buildroot project that often removes (and adds) patch files that have 'Signed-off-by' in their patch description part. Consider only *-by lines that start with [a-z] (case insensitive) to avoid unrelated addresses in cc. Cc: Joe Perches <joe@perches.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-20completion: add more parameter value completionLibravatar Nguyễn Thái Ngọc Duy1-0/+6
This adds value completion for a couple more paramters. To make it easier to maintain these hard coded lists, add a comment at the original list/code to remind people to update git-completion.bash too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'nd/complete-format-patch'Libravatar Junio C Hamano1-0/+8
The support for format-patch (and send-email) by the command-line completion script (in contrib/) has been simplified a bit. * nd/complete-format-patch: completion: use __gitcomp_builtin for format-patch
2018-11-13Merge branch 'al/send-email-auto-cte-fixup'Libravatar Junio C Hamano1-1/+1
"git send-email --transfer-encoding=..." in recent versions of Git sometimes produced an empty "Content-Transfer-Encoding:" header, which has been corrected. * al/send-email-auto-cte-fixup: send-email: avoid empty transfer encoding header
2018-11-06Merge branch 'jw/send-email-no-auth'Libravatar Junio C Hamano1-2/+6
"git send-email" learned to disable SMTP authentication via the "--smtp-auth=none" option, even when the smtp username is given (which turns the authentication on by default). * jw/send-email-no-auth: send-email: explicitly disable authentication
2018-11-06completion: use __gitcomp_builtin for format-patchLibravatar Duy Nguyen1-0/+8
This helps format-patch gain completion for a couple new options, notably --range-diff. Since send-email completion relies on $__git_format_patch_options which is now reduced, we need to do something not to regress send-email completion. The workaround here is implement --git-completion-helper in send-email.perl just as a bridge to "format-patch --git-completion-helper". This is enough to use __gitcomp_builtin on send-email (to take advantage of caching). In the end, send-email.perl can probably reuse the same info it passes to GetOptions() to generate full --git-completion-helper output so that we don't need to keep track of its options in git-completion.bash anymore. But that's something for another boring day. Helped-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02send-email: avoid empty transfer encoding headerLibravatar Aaron Lindsay1-1/+1
Fix a small bug introduced by "7a36987ff (send-email: add an auto option for transfer encoding, 2018-07-14)". I saw the following message when setting --transfer-encoding for a file with the same encoding: $ git send-email --transfer-encoding=8bit example.patch Use of uninitialized value $xfer_encoding in concatenation (.) or string at /usr/lib/git-core/git-send-email line 1744. The new tests are by brian m. carlson. Signed-off-by: Aaron Lindsay <aaron@aclindsay.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-23send-email: explicitly disable authenticationLibravatar Joshua Watt1-2/+6
It can be necessary to disable SMTP authentication by a mechanism other than sendemail.smtpuser being undefined. For example, if the user has sendemail.smtpuser set globally but wants to disable authentication locally in one repository. --smtp-auth and sendemail.smtpauth now understand the value 'none' which means to disable authentication completely, even if an authentication user is specified. The value 'none' is lower case to avoid conflicts with any RFC 4422 authentication mechanisms. The user may also specify the command line argument --no-smtp-auth as a shorthand for --smtp-auth=none Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16send-email: also pick up cc addresses from -by trailersLibravatar Rasmus Villemoes1-7/+12
When rerolling a patch series, including various Reviewed-by etc. that may have come in, it is quite convenient to have git-send-email automatically cc those people. So pick up any *-by lines, with a new suppression category 'misc-by', but special-case Signed-off-by, since that already has its own suppression category. It seems natural to make 'misc-by' implied by 'body'. Based-on-patch-by: Joe Perches <joe@perches.com> Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-11send-email: only consider lines containing @ or <> for automatic Cc'ingLibravatar Rasmus Villemoes1-0/+5
While the address sanitizations routines do accept local addresses, that is almost never what is meant in a Cc or Signed-off-by trailer. Looking through all the signed-off-by lines in the linux kernel tree without a @, there are mostly two patterns: Either just a full name, or a full name followed by <user at domain.com> (i.e., with the word at instead of a @), and minor variations. For cc lines, the same patterns appear, along with lots of "cc stable" variations that do not actually name stable@vger.kernel.org Cc: stable # introduced pre-git times cc: stable.kernel.org In the <user at domain.com> cases, one gets a chance to interactively fix it. But when there is no <> pair, it seems we end up just using the first word as a (local) address. As the number of cases where a local address really was meant is likely (and anecdotally) quite small compared to the number of cases where we end up cc'ing a garbage address, insist on at least a @ or a <> pair being present. This is also preparation for the next patch, where we are likely to encounter even more non-addresses in -by lines, such as Reported-by: Coverity Patch-generated-by: Coccinelle Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'jm/send-email-tls-auth-on-batch'Libravatar Junio C Hamano1-2/+1
"git send-email" when using in a batched mode that limits the number of messages sent in a single SMTP session lost the contents of the variable used to choose between tls/ssl, unable to send the second and later batches, which has been fixed. * jm/send-email-tls-auth-on-batch: send-email: fix tls AUTH when sending batch
2018-07-16send-email: fix tls AUTH when sending batchLibravatar Jules Maselbas1-2/+1
The variable smtp_encryption must keep it's value between two batches. Otherwise the authentication is skipped after the first batch. Signed-off-by: Jules Maselbas <jules.maselbas@grenoble-inp.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: automatically determine transfer-encodingLibravatar brian m. carlson1-12/+6
git send-email, when invoked without a --transfer-encoding option, sends 8bit data without a MIME version or a transfer encoding. This has several downsides. First, unless the transfer encoding is specified, it defaults to 7bit, meaning that non-ASCII data isn't allowed. Second, if lines longer than 998 bytes are used, we will send an message that is invalid according to RFC 5322. The --validate option, which is the default, catches this issue, but it isn't clear to many people how to resolve this. To solve these issues, default the transfer encoding to "auto", so that we explicitly specify 8bit encoding when lines don't exceed 998 bytes and quoted-printable otherwise. This means that we now always emit Content-Transfer-Encoding and MIME-Version headers, so remove the conditionals from this portion of the code. It is unlikely that the unconditional inclusion of these two headers will affect the deliverability of messages in anything but a positive way, since MIME is already widespread and well understood by most email programs. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: accept long lines with suitable transfer encodingLibravatar brian m. carlson1-7/+11
With --validate (which is the default), we warn about lines exceeding 998 characters due to the limits specified in RFC 5322. However, if we're using a suitable transfer encoding (quoted-printable or base64), we're guaranteed not to have lines exceeding 76 characters, so there's no need to fail in this case. The auto transfer encoding handles this specific case, so accept it as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: add an auto option for transfer encodingLibravatar brian m. carlson1-5/+7
For most patches, using a transfer encoding of 8bit provides good compatibility with most servers and makes it as easy as possible to view patches. However, there are some patches for which 8bit is not a valid encoding: RFC 5322 specifies that a message must not have lines exceeding 998 octets. Add a transfer encoding value, auto, which indicates that a patch should use 8bit where allowed and quoted-printable otherwise. Choose quoted-printable instead of base64, since base64-encoded plain text is treated as suspicious by some spam filters. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30Merge branch 'dd/send-email-reedit'Libravatar Junio C Hamano1-7/+31
"git send-email" can sometimes offer confirmation dialog "Send this email?" with choices 'Yes', 'No', 'Quit', and 'All'. A new action 'Edit' has been added to this dialog's choice. * dd/send-email-reedit: git-send-email: allow re-editing of message
2018-05-06git-send-email: allow re-editing of messageLibravatar Drew DeVault1-7/+31
When shown the email summary, an opportunity is presented for the user to edit the email as if they had specified --annotate. This also permits them to edit it multiple times. Signed-off-by: Drew DeVault <sir@cmpwn.com> Reviewed-by: Simon Ser <contact@emersion.fr> Helped-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-19send-email: avoid duplicate In-Reply-To/ReferencesLibravatar Stefan Agner1-1/+6
In case a patch already has In-Reply-To or References in the header (e.g. when the patch has been created with format-patch --thread) git-send-email should not add another pair of those headers. This is also not allowed according to RFC 5322 Section 3.6: https://tools.ietf.org/html/rfc5322#section-3.6 Avoid the second pair by reading the current headers into the appropriate variables. Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>