summaryrefslogtreecommitdiff
path: root/t/t9001-send-email.sh
AgeCommit message (Collapse)AuthorFilesLines
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
2018-03-06send-email: support separate Reply-To addressLibravatar Christian Ludwig1-0/+2
In some projects contributions from groups are only accepted from a common group email address. But every individual may want to receive replies to her own personal address. That's what we have 'Reply-To' headers for in SMTP. So introduce an optional '--reply-to' command line option. This patch re-uses the $reply_to variable. This could break out-of-tree patches! Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-13Merge branch 'cl/t9001-cleanup'Libravatar Junio C Hamano1-10/+7
Test clean-up. * cl/t9001-cleanup: t9001: use existing helper in send-email test
2018-01-12t9001: use existing helper in send-email testLibravatar Christian Ludwig1-10/+7
Use the wrapper function around the sed statement like everywhere else in the test. Unfortunately the wrapper function is defined pretty late. Move the wrapper to the top of the test file, so future users have it available right away. Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08send-email: add test for Linux's get_maintainer.plLibravatar Alex Bennée1-0/+19
We had a regression that broke Linux's get_maintainer.pl. Using Mail::Address to parse email addresses fixed it, but let's protect against future regressions. Note that we need --cc-cmd to be relative because this option doesn't accept spaces in script names (probably to allow --cc-cmd="executable --option"), while --smtp-server needs to be absolute. Patch-edited-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07tests: fix diff order arguments in test_cmpLibravatar Stefan Beller1-3/+3
Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-24send-email: fix garbage removal after addressLibravatar Matthieu Moy1-0/+4
This is a followup over 9d33439 (send-email: only allow one address per body tag, 2017-02-20). The first iteration did allow writting Cc: <foo@example.com> # garbage but did so by matching the regex ([^>]*>?), i.e. stop after the first instance of '>'. However, it did not properly deal with Cc: foo@example.com # garbage Fix this using a new function strip_garbage_one_address, which does essentially what the old ([^>]*>?) was doing, but dealing with more corner-cases. Since we've allowed Cc: "Foo # Bar" <foobar@example.com> in previous versions, it makes sense to continue allowing it (but we still remove any garbage after it). OTOH, when an address is given without quoting, we just take the first word and ignore everything after. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-02send-email: check for repo before invoking hookLibravatar Jonathan Tan1-0/+8
Unless --no-validate is passed, send-email will invoke $repo->repo_path() in its search for a validate hook regardless of whether a Git repo is actually present. Teach send-email to first check for repo existence. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16send-email: support validate hookLibravatar Jonathan Tan1-0/+40
Currently, send-email has support for rudimentary e-mail validation. Allow the user to add support for more validation by providing a sendemail-validate hook. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-10Merge branch 'jh/send-email-one-cc'Libravatar Junio C Hamano1-4/+3
"Cc:" on the trailer part does not have to conform to RFC strictly, unlike in the e-mail header. "git send-email" has been updated to ignore anything after '>' when picking addresses, to allow non-address cruft like " # stable 4.4" after the address. * jh/send-email-one-cc: send-email: only allow one address per body tag
2017-02-27send-email: only allow one address per body tagLibravatar Johan Hovold1-4/+3
Adding comments after a tag in the body is a common practise (e.g. in the Linux kernel) and git-send-email has been supporting this for years by removing any trailing cruft after the address. After some recent changes, any trailing comment is now instead appended to the recipient name (with some random white space inserted) resulting in undesirable noise in the headers, for example: CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org> Revert to the earlier behaviour of discarding anything after the (first) address in a tag while parsing the body. Note that multiple addresses after are still allowed after a command line switch (and in a CC header field). Also note that --suppress-cc=self was never honoured when using multiple addresses in a tag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07don't use test_must_fail with grepLibravatar Pranit Bauva1-1/+1
test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-29Merge branch 'mm/send-email-cc-cruft-after-address' into maintLibravatar Junio C Hamano1-0/+29
"git send-email" attempts to pick up valid e-mails from the trailers, but people in real world write non-addresses there, like "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending on the availability and vintage of Mail::Address perl module. * mm/send-email-cc-cruft-after-address: Git.pm: add comment pointing to t9000 t9000-addresses: update expected results after fix parse_mailboxes: accept extra text after <...> address
2016-10-26Merge branch 'mm/send-email-cc-cruft-after-address'Libravatar Junio C Hamano1-0/+29
"git send-email" attempts to pick up valid e-mails from the trailers, but people in real world write non-addresses there, like "Cc: Stable <add@re.ss> # 4.8+", which broke the output depending on the availability and vintage of Mail::Address perl module. * mm/send-email-cc-cruft-after-address: Git.pm: add comment pointing to t9000 t9000-addresses: update expected results after fix parse_mailboxes: accept extra text after <...> address
2016-10-14parse_mailboxes: accept extra text after <...> addressLibravatar Matthieu Moy1-0/+29
The test introduced in this commit succeeds without the patch to Git.pm if Mail::Address is installed, but fails otherwise because our in-house parser does not accept any text after the email address. They succeed both with and without Mail::Address after this commit. Mail::Address accepts extra text and considers it as part of the name, iff the address is surrounded with <...>. The implementation mimics this behavior as closely as possible. This mostly restores the behavior we had before b1c8a11 (send-email: allow multiple emails using --cc, --to and --bcc, 2015-06-30), but we keep the possibility to handle comma-separated lists. Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-22Merge branch 'ep/shell-command-substitution-style'Libravatar Junio C Hamano1-6/+6
A shell script style update to change `command substitution` into $(command substitution). Coverts contrib/ and much of the t/ directory contents. * ep/shell-command-substitution-style: (92 commits) t9901-git-web--browse.sh: use the $( ... ) construct for command substitution t9501-gitweb-standalone-http-status.sh: use the $( ... ) construct for command substitution t9350-fast-export.sh: use the $( ... ) construct for command substitution t9300-fast-import.sh: use the $( ... ) construct for command substitution t9150-svk-mergetickets.sh: use the $( ... ) construct for command substitution t9145-git-svn-master-branch.sh: use the $( ... ) construct for command substitution t9138-git-svn-authors-prog.sh: use the $( ... ) construct for command substitution t9137-git-svn-dcommit-clobber-series.sh: use the $( ... ) construct for command substitution t9132-git-svn-broken-symlink.sh: use the $( ... ) construct for command substitution t9130-git-svn-authors-file.sh: use the $( ... ) construct for command substitution t9129-git-svn-i18n-commitencoding.sh: use the $( ... ) construct for command substitution t9119-git-svn-info.sh: use the $( ... ) construct for command substitution t9118-git-svn-funky-branch-names.sh: use the $( ... ) construct for command substitution t9114-git-svn-dcommit-merge.sh: use the $( ... ) construct for command substitution t9110-git-svn-use-svm-props.sh: use the $( ... ) construct for command substitution t9109-git-svn-multi-glob.sh: use the $( ... ) construct for command substitution t9108-git-svn-glob.sh: use the $( ... ) construct for command substitution t9107-git-svn-migrate.sh: use the $( ... ) construct for command substitution t9105-git-svn-commit-diff.sh: use the $( ... ) construct for command substitution t9104-git-svn-follow-parent.sh: use the $( ... ) construct for command substitution ...
2016-01-20Merge branch 'ew/send-email-mutt-alias-fix'Libravatar Junio C Hamano1-0/+15
"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-11t/t9001-send-email.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-6/+6
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-04git-send-email: do not double-escape quotes from muttLibravatar Eric Wong1-0/+15
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-11-20sendemail: teach git-send-email to dump alias namesLibravatar Jacob Keller1-0/+82
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-08-03Merge branch 'rl/send-email-aliases'Libravatar Junio C Hamano1-10/+144
"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/+24
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-0/+44
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>