summaryrefslogtreecommitdiff
path: root/t/t9001-send-email.sh
AgeCommit message (Collapse)AuthorFilesLines
2022-03-17tests: change "mkdir -p && write_script" to use "test_hook"Libravatar Ævar Arnfjörð Bjarmason1-3/+1
Change tests that used a "mkdir -p .git/hooks && write_script" pattern to use the new "test_hook" helper instead. The new helper does not create the .git/hooks directory, rather we assume that the default template will do so for us. An upcoming series[1] will extend "test_hook" to operate in a "--template=" mode, but for now assuming that we have a .git/hooks already is a safe assumption. If that assumption becomes false in the future we'll only need to change 'test_hook", instead of all of these callsites. 1. https://lore.kernel.org/git/cover-00.13-00000000000-20211212T201308Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-07send-email: use 'git hook run' for 'sendemail-validate'Libravatar Emily Shaffer1-2/+2
Change the "sendmail-validate" hook to be run via the "git hook run" wrapper instead of via a direct invocation. This is the smallest possibly change to get "send-email" using "git hook run". We still check the hook itself with "-x", and set a "GIT_DIR" variable, both of which are asserted by our tests. We'll need to get rid of this special behavior if we start running N hooks, but for now let's be as close to bug-for-bug compatible as possible. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-15Merge branch 'ab/send-email-config-fix'Libravatar Junio C Hamano1-0/+15
Regression fix. * ab/send-email-config-fix: send-email: fix a "first config key wins" regression in v2.33.0
2021-09-10Merge branch 'mh/send-email-reset-in-reply-to'Libravatar Junio C Hamano1-0/+45
Even when running "git send-email" without its own threaded discussion support, a threading related header in one message is carried over to the subsequent message to result in an unwanted threading, which has been corrected. * mh/send-email-reset-in-reply-to: send-email: avoid incorrect header propagation
2021-09-08Merge branch 'ga/send-email-sendmail-cmd'Libravatar Junio C Hamano1-1/+1
Test fix. * ga/send-email-sendmail-cmd: t9001: PATH must not use Windows-style paths
2021-09-07send-email: fix a "first config key wins" regression in v2.33.0Libravatar Ævar Arnfjörð Bjarmason1-0/+15
Fix a regression in my c95e3a3f0b8 (send-email: move trivial config handling to Perl, 2021-05-28) where we'd pick the first config key out of multiple defined ones, instead of using the normal "last key wins" semantics of "git config --get". This broke e.g. cases where a .git/config would have a different sendemail.smtpServer than ~/.gitconfig. We'd pick the ~/.gitconfig over .git/config, instead of preferring the repository-local version. The same would go for /etc/gitconfig etc. The full list of impacted config keys (the %config_settings values which are references to scalars, not arrays) is: sendemail.smtpencryption sendemail.smtpserver sendemail.smtpserverport sendemail.smtpuser sendemail.smtppass sendemail.smtpdomain sendemail.smtpauth sendemail.smtpbatchsize sendemail.smtprelogindelay sendemail.tocmd sendemail.cccmd sendemail.aliasfiletype sendemail.envelopesender sendemail.confirm sendemail.from sendemail.assume8bitencoding sendemail.composeencoding sendemail.transferencoding sendemail.sendmailcmd I.e. having any of these set in say ~/.gitconfig and in-repo .git/config regressed in v2.33.0 to prefer the --global one over the --local. To test this add a test of config priority to one of these config variables, most don't have tests at all, but there was an existing one for sendemail.8bitEncoding. The "git config" (instead of "test_config") is somewhat of an anti-pattern, but follows established conventions in t9001-send-email.sh, likewise with any other pattern or idiom in this test. The populating of home/.gitconfig and setting of HOME= is copied from a test in t0017-env-helper.sh added in 1ff750b128e (tests: make GIT_TEST_GETTEXT_POISON a boolean, 2019-06-21). This test fails without this bugfix, but now it works. Reported-by: Eli Schwartz <eschwartz@archlinux.org> Tested-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-30send-email: avoid incorrect header propagationLibravatar Marvin Häuser1-0/+45
If multiple independent patches are sent with send-email, even if the "In-Reply-To" and "References" headers are not managed by --thread or --in-reply-to, their values may be propagated from prior patches to subsequent patches with no such headers defined. To mitigate this and potential future issues, make sure all global patch-specific variables are always either handled by command-specific code (e.g. threading), or are reset to their default values for every iteration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Marvin Häuser <mhaeuser@posteo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24t9001: PATH must not use Windows-style pathsLibravatar Johannes Sixt1-1/+1
On Windows, $(pwd) returns a drive-letter style path C:/foo, while $PWD contains a POSIX style /c/foo path. When we want to interpolate the current directory in the PATH variable, we must not use the C:/foo style, because the meaning of the colon is ambiguous. Use the POSIX style. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22Merge branch 'ab/send-email-optim'Libravatar Junio C Hamano1-0/+29
"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-07-08Merge branch 'ar/more-typofix'Libravatar Junio C Hamano1-1/+1
Typofixes. * ar/more-typofix: git-worktree.txt: fix typo in example path t: fix typos in test messages blame: correct name of config option in docs
2021-06-28t: fix typos in test messagesLibravatar Andrei Rybak1-1/+1
Both in t4258 and in t9001, the code of the tests following shows the proper name for the configuration variables. So use the correct names in the test messages as well. Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-06-14Merge branch 'ga/send-email-sendmail-cmd'Libravatar Junio C Hamano1-0/+31
"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-28send-email tests: test for boolean variables without a valueLibravatar Ævar Arnfjörð Bjarmason1-0/+29
The Git.pm code does its own Perl-ifying of boolean variables, let's ensure that empty values = true for boolean variables, as in the C code. 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-3/+4
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: don't needlessly abs_path() the core.hooksPathLibravatar Ævar Arnfjörð Bjarmason1-3/+4
In c8243933c74 (git-send-email: Respect core.hooksPath setting, 2021-03-23) we started supporting core.hooksPath in "send-email". It's been reported that on Windows[1] doing this by calling abs_path() results in different canonicalizations of the absolute path. This wasn't an issue in c8243933c74 itself, but was revealed by my ea7811b37e0 (git-send-email: improve --validate error output, 2021-04-06) when we started emitting the path to the hook, which was previously only internal to git-send-email.perl. The just-landed 53753a37d09 (t9001-send-email.sh: fix expected absolute paths on Windows, 2021-05-24) narrowly fixed this issue, but I believe we can do better here. We should not be relying on whatever changes Perl's abs_path() makes to the path "rev-parse --git-path hooks" hands to us. Let's instead trust it, and hand it to Perl's system() in git-send-email.perl. It will handle either a relative or absolute path. So let's revert most of 53753a37d09 and just have "hooks_path" return what we get from "rev-parse" directly without modification. This has the added benefit of making the error message friendlier in the common case, we'll no longer print an absolute path for repository-local hook errors. 1. http://lore.kernel.org/git/bb30fe2b-cd75-4782-24a6-08bb002a0367@kdbg.org Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-25Merge branch 'jt/send-email-validate-errors-fix'Libravatar Junio C Hamano1-4/+3
Fix a test breakage. * jt/send-email-validate-errors-fix: t9001-send-email.sh: fix expected absolute paths on Windows
2021-05-25send-email: fix missing error message regressionLibravatar Ævar Arnfjörð Bjarmason1-2/+21
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-25t9001-send-email.sh: fix expected absolute paths on WindowsLibravatar Johannes Sixt1-4/+3
Git for Windows is a native Windows program that works with native absolute paths in the drive letter style C:\dir. The auxiliary infrastructure is based on MSYS2, which uses POSIX style /C/dir. When we test for output of absolute paths produced by git.exe, we usally have to expect C:\dir style paths. To produce such expected paths, we have to use $(pwd) in the test scripts; the alternative, $PWD, produces a POSIX style path. ($PWD is a shell variable, and the shell is bash, an MSYS2 program, and operates in the POSIX realm.) There are two recently added tests that were written to expect C:\dir paths. The output that is tested is produced by `git send-email`, but behind the scenes, this is a Perl script, which also works in the POSIX realm and produces /C/dir style output. In the first test case that is changed here, replace $(pwd) by $PWD so that the expected path is constructed using /C/dir style. The second test case sets core.hooksPath to an absolute path. Since the test script talks to native git.exe, it is supposed to place a C:/dir style path into the configuration; therefore, keep $(pwd). When this configuration value is consumed by the Perl script, it is transformed to /C/dir style by the MSYS2 layer and echoed back in this form in the error message. Hence, do use $PWD for the expected value. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-17git-send-email: add option to specify sendmail commandLibravatar Gregory Anders1-0/+31
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-5/+12
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: test full --validate outputLibravatar Ævar Arnfjörð Bjarmason1-6/+18
Change the tests that grep substrings out of the output to use a full test_cmp, in preparation for improving the output. 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-0/+32
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-11-19t9[0-4]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-15/+15
This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t9[0-4]*.sh) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-17Merge branch 'dd/send-email-config'Libravatar Junio C Hamano1-0/+29
Stop when "sendmail.*" configuration variables are defined, which could be a mistaken attempt to define "sendemail.*" variables. * dd/send-email-config: git-send-email: die if sendmail.* config is set
2020-08-06t: don't spuriously close and reopen quotesLibravatar Martin Ågren1-5/+5
In the test scripts, the recommended style is, e.g.: test_expect_success 'name' ' do-something somehow && do-some-more testing ' When using this style, any single quote in the multi-line test section is actually closing the lone single quotes that surround it. It can be a non-issue in practice: test_expect_success 'sed a little' ' sed -e 's/hi/lo/' in >out # "ok": no whitespace in s/hi/lo/ ' Or it can be a bug in the test, e.g., because variable interpolation happens before the test even begins executing: v=abc test_expect_success 'variable interpolation' ' v=def && echo '"$v"' # abc ' Change several such in-test single quotes to use double quotes instead or, in a few cases, drop them altogether. These were identified using some crude grepping. We're not fixing any test bugs here, but we're hopefully making these tests slightly easier to grok and to maintain. There are legitimate use cases for closing a quote and opening a new one, e.g., both '\'' and '"'"' can be used to produce a literal single quote. I'm not touching any of those here. In t9401, tuck the redirecting ">" to the filename while we're touching those lines. Signed-off-by: Martin Ågren <martin.agren@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/+29
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-1/+13
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>
2020-02-17Merge branch 'js/test-avoid-pipe'Libravatar Junio C Hamano1-2/+2
Test clean-up. * js/test-avoid-pipe: t9001, t9116: avoid pipes
2020-02-14t9001, t9116: avoid pipesLibravatar Johannes Schindelin1-2/+2
When grepping through the output of a command in the test suite, there is always a chance that something goes wrong, in which case there would not be anything useful to debug. Let's redirect the output into a file instead, and grep that file, so that the log can be inspected easily if the grep fails. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'bc/t9001-zsh-in-posix-emulation-mode'Libravatar Junio C Hamano1-1/+1
Test portability fix. * bc/t9001-zsh-in-posix-emulation-mode: t9001: avoid including non-trailing NUL bytes in variables
2019-11-30t9001: avoid including non-trailing NUL bytes in variablesLibravatar brian m. carlson1-1/+1
In this test, we have a command substitution whose output starts with a NUL byte. bash and dash strip out any NUL bytes from the output; zsh does not. As a consequence, zsh fails this test, since the command line argument we use the variable in is truncated by the NUL byte. POSIX says of a command substitution that if "the output contains any null bytes, the behavior is unspecified," so all of the shells are in compliance with POSIX. To make our code more portable, let's avoid prefacing our variables with NUL bytes and instead leave only the trailing one behind. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Fix spelling errors in names of testsLibravatar 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-20/+82
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-0/+64
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-19send-email: fix broken transferEncoding testsLibravatar Ævar Arnfjörð Bjarmason1-24/+11
I fixed a bug that had broken the reading of sendmail.transferEncoding in 3494dfd3ee ("send-email: do defaults -> config -> getopt in that order", 2019-05-09), but the test I added in that commit did nothing to assert the bug had been fixed. That issue originates in 8d81408435 ("git-send-email: add --transfer-encoding option", 2014-11-25) which first added the "sendemail.transferencoding=8bit". That test has never done anything meaningful. It tested that the "--transfer-encoding=8bit" option would turn on the 8bit Transfer-Encoding, but that was the default at the time (and now). As checking out 8d81408435 and editing the test to remove that option will reveal, supplying it never did anything. So when I copied it thinking it would work in 3494dfd3ee I copied a previously broken test, although I was making sure it did the right thing via da-hoc debugger inspection, so the bug was fixed. So fix the test I added in 3494dfd3ee, as well as the long-standing test added in 8d81408435. To test if we're actually setting the Transfer-Encoding let's set it to 7bit, not 8bit, as 7bit will error out on "email-using-8bit". This means that we can remove the "sendemail.transferencoding=7bit fails on 8bit data" test, since it was redundant, we now have other tests that assert that that'll fail. While I'm at it convert "git config <key> <value>" in the test setup to just "-c <key>=<value>" on the command-line. Then we don't need to cleanup after these tests, and there's no sense in asserting where config values come from in these tests, we can take that as a given. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19send-email: remove cargo-culted multi-patch pattern in testsLibravatar Ævar Arnfjörð Bjarmason1-7/+7
Change test code added in f434c083a0 ("send-email: add --no-cc, --no-to, and --no-bcc", 2010-03-07) which blindly copied a pattern from an earlier test added in 32ae83194b ("add a test for git-send-email for non-threaded mails", 2009-06-12) where the "$patches" variable was supplied more than once. As it turns out we didn't need more than one "$patches" for the test added in 32ae83194b either. The only tests that actually needed this sort of invocation were the tests added in 54aae5e1a0 ("t9001: send-email interation with --in-reply-to and --chain-reply-to", 2010-10-19). 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-1/+12
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-04-14send-email: default to quoted-printable when CR is presentLibravatar brian m. carlson1-0/+14
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>
2018-11-13Merge branch 'al/send-email-auto-cte-fixup'Libravatar Junio C Hamano1-0/+15
"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-02send-email: avoid empty transfer encoding headerLibravatar Aaron Lindsay1-0/+15
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-08-20Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-2/+1
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-08-02Merge branch 'es/test-fixes'Libravatar Junio C Hamano1-5/+5
Test clean-up and corrections. * es/test-fixes: (26 commits) t5608: fix broken &&-chain t9119: fix broken &&-chains t9000-t9999: fix broken &&-chains t7000-t7999: fix broken &&-chains t6000-t6999: fix broken &&-chains t5000-t5999: fix broken &&-chains t4000-t4999: fix broken &&-chains t3030: fix broken &&-chains t3000-t3999: fix broken &&-chains t2000-t2999: fix broken &&-chains t1000-t1999: fix broken &&-chains t0000-t0999: fix broken &&-chains t9814: simplify convoluted check that command correctly errors out t9001: fix broken "invoke hook" test t7810: use test_expect_code() instead of hand-rolled comparison t7400: fix broken "submodule add/reconfigure --force" test t7201: drop pointless "exit 0" at end of subshell t6036: fix broken "merge fails but has appropriate contents" tests t5505: modernize and simplify hard-to-digest test t5406: use write_script() instead of birthing shell script manually ...
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t9000-t9999: fix broken &&-chainsLibravatar Eric Sunshine1-3/+3
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t9001: fix broken "invoke hook" testLibravatar Eric Sunshine1-2/+2
This test has been dysfunctional since it was added by 6489660b4b (send-email: support validate hook, 2017-05-12), however, the problem went unnoticed due to a broken &&-chain late in the test. The test wants to verify that a non-zero exit code from the 'sendemail-validate' hook causes git-send-email to abort with a particular error message. A command which is expected to fail should be run with 'test_must_fail', however, the test neglects to do so. Fix this problem, as well as the broken &&-chain behind which the problem hid. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-09send-email: automatically determine transfer-encodingLibravatar brian m. carlson1-0/+21
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-0/+13
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-0/+23
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-03-15Merge branch 'cl/send-email-reply-to'Libravatar Junio C Hamano1-0/+2
"git send-email" learned "--reply-to=<address>" option. * cl/send-email-reply-to: send-email: support separate Reply-To address send-email: rename variable for clarity