git-commit-vandalism/t/t9001-send-email.sh

2228 lines
62 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='git send-email'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` 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-11-19 00:44:19 +01:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
# May be altered later in the test
PREREQ="PERL"
replace_variable_fields () {
sed -e "s/^\(Date:\).*/\1 DATE-STRING/" \
-e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
-e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/"
}
test_expect_success $PREREQ 'prepare reference tree' '
echo "1A quick brown fox jumps over the" >file &&
echo "lazy dog" >>file &&
git add file &&
GIT_AUTHOR_NAME="A" git commit -a -m "Initial."
'
test_expect_success $PREREQ 'Setup helper tool' '
write_script fake.sendmail <<-\EOF &&
shift
output=1
while test -f commandline$output
do
output=$(($output+1))
done
for a
do
echo "!$a!"
done >commandline$output
cat >"msgtxt$output"
EOF
git add fake.sendmail &&
GIT_AUTHOR_NAME="A" git commit -a -m "Second."
'
clean_fake_sendmail () {
rm -f commandline* msgtxt*
}
test_expect_success $PREREQ 'Extract patches' '
patches=$(git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1) &&
threaded_patches=$(git format-patch -o threaded -s --in-reply-to="format" HEAD^1)
'
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
# Test no confirm early to ensure remaining tests will not hang
test_no_confirm () {
rm -f no_confirm_okay
echo n | \
GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--from="Example <from@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$@ \
$patches >stdout &&
! grep "Send this email" stdout &&
>no_confirm_okay
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
}
# Exit immediately to prevent hang if a no-confirm test fails
check_no_confirm () {
if ! test -f no_confirm_okay
then
say 'confirm test failed; skipping remaining tests to prevent hanging'
PREREQ="$PREREQ,CHECK_NO_CONFIRM"
fi
return 0
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
}
test_expect_success $PREREQ 'No confirm with --suppress-cc' '
test_no_confirm --suppress-cc=sob &&
check_no_confirm
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
'
test_expect_success $PREREQ 'No confirm with --confirm=never' '
test_no_confirm --confirm=never &&
check_no_confirm
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
'
# leave sendemail.confirm set to never after this so that none of the
# remaining tests prompt unintentionally.
test_expect_success $PREREQ 'No confirm with sendemail.confirm=never' '
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
git config sendemail.confirm never &&
test_no_confirm --compose --subject=foo &&
check_no_confirm
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
'
test_expect_success $PREREQ 'Send patches' '
git send-email --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
EOF
'
test_expect_success $PREREQ 'Verify commandline' '
test_cmp expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender' '
clean_fake_sendmail &&
git send-email --envelope-sender="Patch Contributor <patch@example.com>" --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
!patch@example.com!
!-i!
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
EOF
'
test_expect_success $PREREQ 'Verify commandline' '
test_cmp expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender=auto' '
clean_fake_sendmail &&
git send-email --envelope-sender=auto --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
!nobody@example.com!
!-i!
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
EOF
'
test_expect_success $PREREQ 'Verify commandline' '
test_cmp expected commandline1
'
test_expect_success $PREREQ 'setup expect for cc trailer' "
cat >expected-cc <<\EOF
!recipient@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
!three@example.com!
!four@example.com!
!five@example.com!
!six@example.com!
EOF
"
test_expect_success $PREREQ 'cc trailer with various syntax' '
test_commit cc-trailer &&
test_when_finished "git reset --hard HEAD^" &&
git commit --amend -F - <<-EOF &&
Test Cc: trailers.
Cc: one@example.com
Cc: <two@example.com> # trailing comments are ignored
Cc: <three@example.com>, <not.four@example.com> one address per line
Cc: "Some # Body" <four@example.com> [ <also.a.comment> ]
Cc: five@example.com # not.six@example.com
Cc: six@example.com, not.seven@example.com
EOF
clean_fake_sendmail &&
git send-email -1 --to=recipient@example.com \
--smtp-server="$(pwd)/fake.sendmail" &&
test_cmp expected-cc commandline1
'
test_expect_success $PREREQ 'setup fake get_maintainer.pl script for cc trailer' "
write_script expected-cc-script.sh <<-EOF
echo 'One Person <one@example.com> (supporter:THIS (FOO/bar))'
echo 'Two Person <two@example.com> (maintainer:THIS THING)'
echo 'Third List <three@example.com> (moderated list:THIS THING (FOO/bar))'
echo '<four@example.com> (moderated list:FOR THING)'
echo 'five@example.com (open list:FOR THING (FOO/bar))'
echo 'six@example.com (open list)'
EOF
"
test_expect_success $PREREQ 'cc trailer with get_maintainer.pl output' '
clean_fake_sendmail &&
git send-email -1 --to=recipient@example.com \
--cc-cmd=./expected-cc-script.sh \
--smtp-server="$(pwd)/fake.sendmail" &&
test_cmp expected-cc commandline1
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-show-all-headers <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<cc@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
RCPT TO:<bcc@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: cc@example.com,
A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
In-Reply-To: <unique-message-id@example.com>
References: <unique-message-id@example.com>
Reply-To: Reply <reply@example.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_suppress_self () {
test_commit $3 &&
test_when_finished "git reset --hard HEAD^" &&
write_script cccmd-sed <<-EOF &&
sed -n -e s/^cccmd--//p "\$1"
EOF
git commit --amend --author="$1 <$2>" -F - &&
clean_fake_sendmail &&
git format-patch --stdout -1 >"suppress-self-$3.patch" &&
git send-email --from="$1 <$2>" \
--to=nobody@example.com \
--cc-cmd=./cccmd-sed \
--suppress-cc=self \
--smtp-server="$(pwd)/fake.sendmail" \
suppress-self-$3.patch &&
mv msgtxt1 msgtxt1-$3 &&
sed -e '/^$/q' msgtxt1-$3 >"msghdr1-$3" &&
(grep '^Cc:' msghdr1-$3 >"actual-no-cc-$3";
test_must_be_empty actual-no-cc-$3)
}
test_suppress_self_unquoted () {
test_suppress_self "$1" "$2" "unquoted-$3" <<-EOF
test suppress-cc.self unquoted-$3 with name $1 email $2
unquoted-$3
cccmd--$1 <$2>
Cc: $1 <$2>
Signed-off-by: $1 <$2>
EOF
}
test_suppress_self_quoted () {
test_suppress_self "$1" "$2" "quoted-$3" <<-EOF
test suppress-cc.self quoted-$3 with name $1 email $2
quoted-$3
cccmd--"$1" <$2>
Cc: $1 <$2>
Cc: "$1" <$2>
Signed-off-by: $1 <$2>
Signed-off-by: "$1" <$2>
EOF
}
test_expect_success $PREREQ 'self name is suppressed' "
test_suppress_self_unquoted 'A U Thor' 'author@example.com' \
'self_name_suppressed'
"
test_expect_success $PREREQ 'self name with dot is suppressed' "
test_suppress_self_quoted 'A U. Thor' 'author@example.com' \
'self_name_dot_suppressed'
"
test_expect_success $PREREQ 'non-ascii self name is suppressed' "
test_suppress_self_quoted 'Füñný Nâmé' 'odd_?=mail@example.com' \
'non_ascii_self_suppressed'
"
# This name is long enough to force format-patch to split it into multiple
# encoded-words, assuming it uses UTF-8 with the "Q" encoding.
test_expect_success $PREREQ 'long non-ascii self name is suppressed' "
test_suppress_self_quoted 'Ƒüñníęř €. Nâṁé' 'odd_?=mail@example.com' \
'long_non_ascii_self_suppressed'
"
test_expect_success $PREREQ 'sanitized self name is suppressed' "
test_suppress_self_unquoted '\"A U. Thor\"' 'author@example.com' \
'self_name_sanitized_suppressed'
"
test_expect_success $PREREQ 'Show all headers' '
git send-email \
--dry-run \
--suppress-cc=sob \
--from="Example <from@example.com>" \
--reply-to="Reply <reply@example.com>" \
--to=to@example.com \
--cc=cc@example.com \
--bcc=bcc@example.com \
--in-reply-to="<unique-message-id@example.com>" \
--smtp-server relay.example.com \
$patches | replace_variable_fields \
>actual-show-all-headers &&
test_cmp expected-show-all-headers actual-show-all-headers
'
test_expect_success $PREREQ 'Prompting works' '
clean_fake_sendmail &&
(echo "to@example.com" &&
echo ""
) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
2>errors &&
send-email: avoid questions when user has an ident Currently we keep getting questions even when the user has properly configured his full name and password: Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] And once a question pops up, other questions are turned on. This is annoying. The reason it's safe to avoid this question is because currently the script fails completely when the author (or committer) is not correct, so we won't even be reaching this point in the code. The scenarios, and the current situation: 1) No information at all, no fully qualified domain name fatal: empty ident name (for <felipec@nysa.(none)>) not allowed 2) Only full name fatal: unable to auto-detect email address (got 'felipec@nysa.(none)') 3) Full name + fqdm Who should the emails appear to be from? [Felipe Contreras <felipec@nysa.felipec.org>] 4) Full name + EMAIL Who should the emails appear to be from? [Felipe Contreras <felipe.contreras@gmail.com>] 5) User configured 6) GIT_COMMITTER 7) GIT_AUTHOR All these are the same as 4) After this patch: 1) 2) won't change: git send-email would still die 4) 5) 6) 7) will change: git send-email won't ask the user This is good, that's what we would expect, because the identity is explicit. 3) will change: git send-email won't ask the user This is bad, because we will try with an address such as 'felipec@nysa.felipec.org', which is most likely not what the user wants, but the user will get warned by default (confirm=auto), and if not, most likely the sending won't work, which the user would readily note and fix. The worst possible scenario is that such mail address does work, and the user sends an email from that address unintentionally, when in fact the user expected to correct that address in the prompt. This is a very, very, very unlikely scenario, with many dependencies: 1) No configured user.name/user.email 2) No specified $EMAIL 3) No configured sendemail.from 4) No specified --from argument 5) A fully qualified domain name 6) A full name in the geckos field 7) A sendmail configuration that allows sending from this domain name 8) confirm=never, or 8.1) confirm configuration not hitting, or 8.2) Getting the error, not being aware of it 9) The user expecting to correct this address in the prompt In a more likely scenario where 7) is not the case (can't send from nysa.felipec.org), the user will simply see the mail was not sent properly, and fix the problem. The much more likely scenario though, is where 5) is not the case (nysa.(none)), and git send-email will fail right away like it does now. So the likelihood of this affecting anybody seriously is very very slim, and the chances of this affecting somebody slightly are still very small. The vast majority, if not all, of git users won't be affected negatively, and a lot will benefit from this. Tests-by: Jeff King <peff@peff.net> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-24 12:16:19 +01:00
grep "^From: A U Thor <author@example.com>\$" msgtxt1 &&
grep "^To: to@example.com\$" msgtxt1
'
test_expect_success $PREREQ,AUTOIDENT 'implicit ident is allowed' '
clean_fake_sendmail &&
(sane_unset GIT_AUTHOR_NAME &&
sane_unset GIT_AUTHOR_EMAIL &&
sane_unset GIT_COMMITTER_NAME &&
sane_unset GIT_COMMITTER_EMAIL &&
GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
--to=to@example.com \
$patches </dev/null 2>errors
)
'
test_expect_success $PREREQ,!AUTOIDENT 'broken implicit ident aborts send-email' '
clean_fake_sendmail &&
(sane_unset GIT_AUTHOR_NAME &&
sane_unset GIT_AUTHOR_EMAIL &&
sane_unset GIT_COMMITTER_NAME &&
sane_unset GIT_COMMITTER_EMAIL &&
GIT_SEND_EMAIL_NOTTY=1 && export GIT_SEND_EMAIL_NOTTY &&
test_must_fail git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
--to=to@example.com \
$patches </dev/null 2>errors &&
test_i18ngrep "tell me who you are" errors
)
'
test_expect_success $PREREQ 'setup tocmd and cccmd scripts' '
write_script tocmd-sed <<-\EOF &&
sed -n -e "s/^tocmd--//p" "$1"
EOF
write_script cccmd-sed <<-\EOF
sed -n -e "s/^cccmd--//p" "$1"
EOF
'
test_expect_success $PREREQ 'tocmd works' '
clean_fake_sendmail &&
cp $patches tocmd.patch &&
echo tocmd--tocmd@example.com >>tocmd.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--to-cmd=./tocmd-sed \
--smtp-server="$(pwd)/fake.sendmail" \
tocmd.patch \
&&
grep "^To: tocmd@example.com" msgtxt1
'
test_expect_success $PREREQ 'cccmd works' '
clean_fake_sendmail &&
cp $patches cccmd.patch &&
echo "cccmd-- cccmd@example.com" >>cccmd.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--cc-cmd=./cccmd-sed \
--smtp-server="$(pwd)/fake.sendmail" \
cccmd.patch \
&&
grep "^ cccmd@example.com" msgtxt1
'
test_expect_success $PREREQ 'reject long lines' '
z8=zzzzzzzz &&
z64=$z8$z8$z8$z8$z8$z8$z8$z8 &&
z512=$z64$z64$z64$z64$z64$z64$z64$z64 &&
clean_fake_sendmail &&
cp $patches longline.patch &&
cat >>longline.patch <<-EOF &&
$z512$z512
not a long line
$z512$z512
EOF
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=8bit \
$patches longline.patch \
2>actual &&
cat >expect <<-\EOF &&
fatal: longline.patch:35 is longer than 998 characters
warning: no patches were sent
EOF
test_cmp expect actual
'
test_expect_success $PREREQ 'no patch was sent' '
! test -e commandline1
'
test_expect_success $PREREQ 'Author From: in message body' '
clean_fake_sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
sed "1,/^\$/d" <msgtxt1 >msgbody1 &&
grep "From: A <author@example.com>" msgbody1
'
test_expect_success $PREREQ 'Author From: not in message body' '
clean_fake_sendmail &&
git send-email \
--from="A <author@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
sed "1,/^\$/d" <msgtxt1 >msgbody1 &&
! grep "From: A <author@example.com>" msgbody1
'
test_expect_success $PREREQ 'allow long lines with --no-validate' '
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--no-validate \
$patches longline.patch \
2>errors
'
test_expect_success $PREREQ 'short lines with auto encoding are 8bit' '
clean_fake_sendmail &&
git send-email \
--from="A <author@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=auto \
$patches &&
grep "Content-Transfer-Encoding: 8bit" msgtxt1
'
test_expect_success $PREREQ 'long lines with auto encoding are quoted-printable' '
clean_fake_sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=auto \
--no-validate \
longline.patch &&
grep "Content-Transfer-Encoding: quoted-printable" msgtxt1
'
test_expect_success $PREREQ 'carriage returns with auto encoding are quoted-printable' '
clean_fake_sendmail &&
cp $patches cr.patch &&
printf "this is a line\r\n" >>cr.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=auto \
--no-validate \
cr.patch &&
grep "Content-Transfer-Encoding: quoted-printable" msgtxt1
'
for enc in auto quoted-printable base64
do
test_expect_success $PREREQ "--validate passes with encoding $enc" '
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=$enc \
--validate \
$patches longline.patch
'
done
test_expect_success $PREREQ "--validate respects relative core.hooksPath path" '
clean_fake_sendmail &&
mkdir my-hooks &&
test_when_finished "rm my-hooks.ran" &&
write_script my-hooks/sendemail-validate <<-\EOF &&
>my-hooks.ran
exit 1
EOF
test_config core.hooksPath "my-hooks" &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--validate \
longline.patch 2>actual &&
test_path_is_file my-hooks.ran &&
cat >expect <<-EOF &&
fatal: longline.patch: rejected by sendemail-validate hook
2021-05-24 21:38:09 +02:00
fatal: command '"'"'$PWD/my-hooks/sendemail-validate'"'"' died with exit code 1
warning: no patches were sent
EOF
test_cmp expect actual
'
test_expect_success $PREREQ "--validate respects absolute core.hooksPath path" '
2021-05-24 21:38:09 +02:00
test_config core.hooksPath "$(pwd)/my-hooks" &&
test_when_finished "rm my-hooks.ran" &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--validate \
longline.patch 2>actual &&
test_path_is_file my-hooks.ran &&
cat >expect <<-EOF &&
fatal: longline.patch: rejected by sendemail-validate hook
2021-05-24 21:38:09 +02:00
fatal: command '"'"'$PWD/my-hooks/sendemail-validate'"'"' died with exit code 1
warning: no patches were sent
EOF
test_cmp expect actual
'
for enc in 7bit 8bit quoted-printable base64
do
test_expect_success $PREREQ "--transfer-encoding=$enc produces correct header" '
clean_fake_sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--transfer-encoding=$enc \
$patches &&
grep "Content-Transfer-Encoding: $enc" msgtxt1
'
done
test_expect_success $PREREQ 'Invalid In-Reply-To' '
clean_fake_sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--in-reply-to=" " \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
2>errors &&
! grep "^In-Reply-To: < *>" msgtxt1
'
test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '
clean_fake_sendmail &&
(echo "From Example <from@example.com>" &&
echo "To Example <to@example.com>" &&
echo ""
) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
--smtp-server="$(pwd)/fake.sendmail" \
$patches 2>errors &&
! grep "^In-Reply-To: < *>" msgtxt1
'
test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '
clean_fake_sendmail &&
echo "<unique-message-id@example.com>" >expect &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--no-chain-reply-to \
--in-reply-to="$(cat expect)" \
--smtp-server="$(pwd)/fake.sendmail" \
$patches $patches $patches \
2>errors &&
git-send-email.perl: make initial In-Reply-To apply only to first email When an initial --in-reply-to is supplied, make it apply only to the first message; --[no-]chain-reply-to setting are honored by second and subsequent messages; this is also how the git-format-patch option with the same name behaves. Moreover, when $initial_reply_to is asked to the user interactively it is asked as the "Message-ID to be used as In-Reply-To for the _first_ email", this makes the user think that the second and subsequent patches are not using it but are considered as replies to the first message or chained according to the --[no-]chain-reply setting. Look at the v2 series in the illustration to see what the new behavior ensures: (before the patch) | (after the patch) [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did... [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests [PATCH 2/2] Implementation | [PATCH 2/2] Implementation [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation This is the typical behaviour we want when we send a series with cover letter in reply to some discussion, the new patch series should appear as a separate subtree in the discussion. Also update the documentation on --in-reply-to to describe the new behavior. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12 15:55:08 +01:00
# The first message is a reply to --in-reply-to
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt1 >actual &&
test_cmp expect actual &&
git-send-email.perl: make initial In-Reply-To apply only to first email When an initial --in-reply-to is supplied, make it apply only to the first message; --[no-]chain-reply-to setting are honored by second and subsequent messages; this is also how the git-format-patch option with the same name behaves. Moreover, when $initial_reply_to is asked to the user interactively it is asked as the "Message-ID to be used as In-Reply-To for the _first_ email", this makes the user think that the second and subsequent patches are not using it but are considered as replies to the first message or chained according to the --[no-]chain-reply setting. Look at the v2 series in the illustration to see what the new behavior ensures: (before the patch) | (after the patch) [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did... [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests [PATCH 2/2] Implementation | [PATCH 2/2] Implementation [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation This is the typical behaviour we want when we send a series with cover letter in reply to some discussion, the new patch series should appear as a separate subtree in the discussion. Also update the documentation on --in-reply-to to describe the new behavior. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-12 15:55:08 +01:00
# Second and subsequent messages are replies to the first one
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt1 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt2 >actual &&
test_cmp expect actual &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt3 >actual &&
test_cmp expect actual
'
test_expect_success $PREREQ 'In-Reply-To with --chain-reply-to' '
clean_fake_sendmail &&
echo "<unique-message-id@example.com>" >expect &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--chain-reply-to \
--in-reply-to="$(cat expect)" \
--smtp-server="$(pwd)/fake.sendmail" \
$patches $patches $patches \
2>errors &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt1 >actual &&
test_cmp expect actual &&
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt1 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt2 >actual &&
test_cmp expect actual &&
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt2 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt3 >actual &&
test_cmp expect actual
'
test_expect_success $PREREQ 'setup fake editor' '
write_script fake-editor <<-\EOF
echo fake edit >>"$1"
EOF
'
test_set_editor "$(pwd)/fake-editor"
test_expect_success $PREREQ '--compose works' '
clean_fake_sendmail &&
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches \
2>errors
'
test_expect_success $PREREQ 'first message is compose text' '
grep "^fake edit" msgtxt1
'
test_expect_success $PREREQ 'second message is patch' '
grep "Subject:.*Second" msgtxt2
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<cc@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: cc@example.com,
A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_suppression () {
git send-email \
--dry-run \
--suppress-cc=$1 ${2+"--suppress-cc=$2"} \
--from="Example <from@example.com>" \
--to=to@example.com \
--smtp-server relay.example.com \
$patches | replace_variable_fields \
>actual-suppress-$1${2+"-$2"} &&
test_cmp expected-suppress-$1${2+"-$2"} actual-suppress-$1${2+"-$2"}
}
test_expect_success $PREREQ 'sendemail.cc set' '
git config sendemail.cc cc@example.com &&
test_suppression sob
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ 'sendemail.cc unset' '
git config --unset sendemail.cc &&
test_suppression sob
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cccmd <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
RCPT TO:<committer@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com,
C O Mitter <committer@example.com>
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ 'sendemail.cccmd' '
write_script cccmd <<-\EOF &&
echo cc-cmd@example.com
EOF
git config sendemail.cccmd ./cccmd &&
test_suppression cccmd
'
test_expect_success $PREREQ 'setup expect' '
cat >expected-suppress-all <<\EOF
0001-Second.patch
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
From: Example <from@example.com>
To: to@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
'
test_expect_success $PREREQ '--suppress-cc=all' '
test_suppression all
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
(cc-cmd) Adding cc: cc-cmd@example.com from: './cccmd'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
RCPT TO:<cc-cmd@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com,
cc-cmd@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ '--suppress-cc=body' '
test_suppression body
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body-cccmd <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ '--suppress-cc=body --suppress-cc=cccmd' '
test_suppression body cccmd
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ '--suppress-cc=sob' '
test_might_fail git config --unset sendemail.cccmd &&
test_suppression sob
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-bodycc <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<one@example.com>
RCPT TO:<two@example.com>
RCPT TO:<committer@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
One <one@example.com>,
two@example.com,
C O Mitter <committer@example.com>
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ '--suppress-cc=bodycc' '
test_suppression bodycc
'
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cc <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<author@example.com>
RCPT TO:<committer@example.com>
From: Example <from@example.com>
To: to@example.com
Cc: A <author@example.com>,
C O Mitter <committer@example.com>
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Result: OK
EOF
"
test_expect_success $PREREQ '--suppress-cc=cc' '
test_suppression cc
'
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
test_confirm () {
echo y | \
GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$@ $patches >stdout &&
grep "Send this email" stdout
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
}
test_expect_success $PREREQ '--confirm=always' '
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
test_confirm --confirm=always --suppress-cc=all
'
test_expect_success $PREREQ '--confirm=auto' '
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
test_confirm --confirm=auto
'
test_expect_success $PREREQ '--confirm=cc' '
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
test_confirm --confirm=cc
'
test_expect_success $PREREQ '--confirm=compose' '
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
test_confirm --confirm=compose --compose
'
test_expect_success $PREREQ 'confirm by default (due to cc)' '
test_when_finished git config sendemail.confirm never &&
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
git config --unset sendemail.confirm &&
test_confirm
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
'
test_expect_success $PREREQ 'confirm by default (due to --compose)' '
test_when_finished git config sendemail.confirm never &&
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
git config --unset sendemail.confirm &&
test_confirm --suppress-cc=all --compose
'
test_expect_success $PREREQ 'confirm detects EOF (inform assumes y)' '
test_when_finished git config sendemail.confirm never &&
git config --unset sendemail.confirm &&
rm -fr outdir &&
git format-patch -2 -o outdir &&
GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/*.patch </dev/null
'
test_expect_success $PREREQ 'confirm detects EOF (auto causes failure)' '
test_when_finished git config sendemail.confirm never &&
git config sendemail.confirm auto &&
GIT_SEND_EMAIL_NOTTY=1 &&
export GIT_SEND_EMAIL_NOTTY &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches </dev/null
'
test_expect_success $PREREQ 'confirm does not loop forever' '
test_when_finished git config sendemail.confirm never &&
git config sendemail.confirm auto &&
GIT_SEND_EMAIL_NOTTY=1 &&
export GIT_SEND_EMAIL_NOTTY &&
yes "bogus" | test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches
'
test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch -1 -o outdir --cc="àéìöú <utf8@example.com>" &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/*.patch &&
grep "^ " msgtxt1 |
grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
'
test_expect_success $PREREQ '--compose adds MIME for utf8 body' '
clean_fake_sendmail &&
write_script fake-editor-utf8 <<-\EOF &&
echo "utf8 body: àéìöú" >>"$1"
EOF
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^utf8 body" msgtxt1 &&
grep "^Content-Type: text/plain; charset=UTF-8" msgtxt1
'
test_expect_success $PREREQ '--compose respects user mime type' '
clean_fake_sendmail &&
write_script fake-editor-utf8-mime <<-\EOF &&
cat >"$1" <<-\EOM
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: foo
utf8 body: àéìöú
EOM
EOF
GIT_EDITOR="\"$(pwd)/fake-editor-utf8-mime\"" \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^utf8 body" msgtxt1 &&
grep "^Content-Type: text/plain; charset=iso-8859-1" msgtxt1 &&
! grep "^Content-Type: text/plain; charset=UTF-8" msgtxt1
'
test_expect_success $PREREQ '--compose adds MIME for utf8 subject' '
clean_fake_sendmail &&
GIT_EDITOR="\"$(pwd)/fake-editor\"" \
git send-email \
--compose --subject utf8-sübjëct \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^fake edit" msgtxt1 &&
grep "^Subject: =?UTF-8?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
'
test_expect_success $PREREQ 'utf8 author is correctly passed on' '
clean_fake_sendmail &&
test_commit weird_author &&
test_when_finished "git reset --hard HEAD^" &&
git commit --amend --author "Füñný Nâmé <odd_?=mail@example.com>" &&
git format-patch --stdout -1 >funny_name.patch &&
git send-email --from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
funny_name.patch &&
grep "^From: Füñný Nâmé <odd_?=mail@example.com>" msgtxt1
'
test_expect_success $PREREQ 'utf8 sender is not duplicated' '
clean_fake_sendmail &&
test_commit weird_sender &&
test_when_finished "git reset --hard HEAD^" &&
git commit --amend --author "Füñný Nâmé <odd_?=mail@example.com>" &&
git format-patch --stdout -1 >funny_name.patch &&
git send-email --from="Füñný Nâmé <odd_?=mail@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
funny_name.patch &&
grep "^From: " msgtxt1 >msgfrom &&
test_line_count = 1 msgfrom
'
test_expect_success $PREREQ 'sendemail.composeencoding works' '
clean_fake_sendmail &&
git config sendemail.composeencoding iso-8859-1 &&
write_script fake-editor-utf8 <<-\EOF &&
echo "utf8 body: àéìöú" >>"$1"
EOF
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^utf8 body" msgtxt1 &&
grep "^Content-Type: text/plain; charset=iso-8859-1" msgtxt1
'
test_expect_success $PREREQ '--compose-encoding works' '
clean_fake_sendmail &&
write_script fake-editor-utf8 <<-\EOF &&
echo "utf8 body: àéìöú" >>"$1"
EOF
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
git send-email \
--compose-encoding iso-8859-1 \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^utf8 body" msgtxt1 &&
grep "^Content-Type: text/plain; charset=iso-8859-1" msgtxt1
'
test_expect_success $PREREQ '--compose-encoding overrides sendemail.composeencoding' '
clean_fake_sendmail &&
git config sendemail.composeencoding iso-8859-1 &&
write_script fake-editor-utf8 <<-\EOF &&
echo "utf8 body: àéìöú" >>"$1"
EOF
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
git send-email \
--compose-encoding iso-8859-2 \
--compose --subject foo \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^utf8 body" msgtxt1 &&
grep "^Content-Type: text/plain; charset=iso-8859-2" msgtxt1
'
test_expect_success $PREREQ '--compose-encoding adds correct MIME for subject' '
clean_fake_sendmail &&
GIT_EDITOR="\"$(pwd)/fake-editor\"" \
git send-email \
--compose-encoding iso-8859-2 \
--compose --subject utf8-sübjëct \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$patches &&
grep "^fake edit" msgtxt1 &&
grep "^Subject: =?iso-8859-2?q?utf8-s=C3=BCbj=C3=ABct?=" msgtxt1
'
test_expect_success $PREREQ 'detects ambiguous reference/file conflict' '
echo main >main &&
git add main &&
git commit -m"add main" &&
test_must_fail git send-email --dry-run main 2>errors &&
grep disambiguate errors
'
test_expect_success $PREREQ 'feed two files' '
rm -fr outdir &&
git format-patch -2 -o outdir &&
send-email: add --confirm option and configuration setting send-email violates the principle of least surprise by automatically cc'ing additional recipients without confirming this with the user. This patch teaches send-email a --confirm option. It takes the following values: --confirm=always always confirm before sending --confirm=never never confirm before sending --confirm=cc confirm before sending when send-email has automatically added addresses from the patch to the Cc list --confirm=compose confirm before sending the first message when using --compose. (Needed to maintain backwards compatibility with existing behavior.) --confirm=auto 'cc' + 'compose' If sendemail.confirm is unconfigured, the option defaults to 'compose' if any suppress-Cc related options have been used, otherwise it defaults to 'auto'. Unfortunately, it is impossible to introduce this patch such that it helps new users without potentially annoying some existing users. We attempt to mitigate the latter by: * Allowing the user to set 'git config sendemail.confirm never' * Allowing the user to say 'all' after the first prompt to not be prompted on remaining emails during the same invocation. * Telling the user about the 'sendemail.confirm' setting if it is unconfigured whenever we prompt due to Cc before sending. * Only prompting if no --suppress related options have been passed, as using such an option is likely to indicate an experienced send-email user. There is a slight fib in message informing the user of the sendemail.confirm setting and this is intentional. Setting 'auto' differs from leaving sendemail.confirm unset in two ways: 1) 'auto' obviously squelches the informational message; 2) 'auto' prompts when the Cc list has been expanded even in the presence of a --suppress related option, where leaving sendemail.confirm unset does not. This is intentional to keep the message simple, and to avoid adding another sendemail.confirm value ('auto-except-suppress'?). Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-03 05:52:18 +01:00
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
outdir/000?-*.patch 2>errors >out &&
grep "^Subject: " out >subjects &&
test "z$(sed -n -e 1p subjects)" = "zSubject: [PATCH 1/2] Second." &&
test "z$(sed -n -e 2p subjects)" = "zSubject: [PATCH 2/2] add main"
'
test_expect_success $PREREQ 'in-reply-to but no threading' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--in-reply-to="<in-reply-id@example.com>" \
--no-thread \
$patches >out &&
grep "In-Reply-To: <in-reply-id@example.com>" out
'
test_expect_success $PREREQ 'no in-reply-to and no threading' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--no-thread \
$patches >stdout &&
! grep "In-Reply-To: " stdout
'
test_expect_success $PREREQ 'threading but no chain-reply-to' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--thread \
--no-chain-reply-to \
$patches $patches >stdout &&
grep "In-Reply-To: " stdout
'
test_expect_success $PREREQ 'override in-reply-to if no threading' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--no-thread \
--in-reply-to="override" \
$threaded_patches >stdout &&
grep "In-Reply-To: <override>" stdout
'
test_expect_success $PREREQ 'sendemail.to works' '
git config --replace-all sendemail.to "Somebody <somebody@ex.com>" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
$patches >stdout &&
grep "To: Somebody <somebody@ex.com>" stdout
'
send-email: fix regression in sendemail.identity parsing 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-17 21:55:44 +02:00
test_expect_success $PREREQ 'setup sendemail.identity' '
git config --replace-all sendemail.to "default@example.com" &&
git config --replace-all sendemail.isp.to "isp@example.com" &&
git config --replace-all sendemail.cloud.to "cloud@example.com"
'
test_expect_success $PREREQ 'sendemail.identity: reads the correct identity config' '
git -c sendemail.identity=cloud send-email \
--dry-run \
--from="nobody@example.com" \
$patches >stdout &&
grep "To: cloud@example.com" stdout
'
test_expect_success $PREREQ 'sendemail.identity: identity overrides sendemail.identity' '
git -c sendemail.identity=cloud send-email \
--identity=isp \
--dry-run \
--from="nobody@example.com" \
$patches >stdout &&
grep "To: isp@example.com" stdout
'
test_expect_success $PREREQ 'sendemail.identity: --no-identity clears previous identity' '
git -c sendemail.identity=cloud send-email \
--no-identity \
--dry-run \
--from="nobody@example.com" \
$patches >stdout &&
grep "To: default@example.com" stdout
'
test_expect_success $PREREQ 'sendemail.identity: bool identity variable existence overrides' '
send-email: fix regression in sendemail.identity parsing 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-17 21:55:44 +02:00
git -c sendemail.identity=cloud \
-c sendemail.xmailer=true \
-c sendemail.cloud.xmailer=false \
send-email \
--dry-run \
--from="nobody@example.com" \
$patches >stdout &&
grep "To: cloud@example.com" stdout &&
! grep "X-Mailer" stdout
'
test_expect_success $PREREQ 'sendemail.identity: bool variable fallback' '
git -c sendemail.identity=cloud \
-c sendemail.xmailer=false \
send-email \
--dry-run \
--from="nobody@example.com" \
$patches >stdout &&
grep "To: cloud@example.com" stdout &&
! grep "X-Mailer" stdout
'
test_expect_success $PREREQ '--no-to overrides sendemail.to' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--no-to \
--to=nobody@example.com \
$patches >stdout &&
grep "To: nobody@example.com" stdout &&
! grep "To: Somebody <somebody@ex.com>" stdout
'
test_expect_success $PREREQ 'sendemail.cc works' '
git config --replace-all sendemail.cc "Somebody <somebody@ex.com>" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
$patches >stdout &&
grep "Cc: Somebody <somebody@ex.com>" stdout
'
test_expect_success $PREREQ '--no-cc overrides sendemail.cc' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--no-cc \
--cc=bodies@example.com \
--to=nobody@example.com \
$patches >stdout &&
grep "Cc: bodies@example.com" stdout &&
! grep "Cc: Somebody <somebody@ex.com>" stdout
'
test_expect_success $PREREQ 'sendemail.bcc works' '
git config --replace-all sendemail.bcc "Other <other@ex.com>" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server relay.example.com \
$patches >stdout &&
grep "RCPT TO:<other@ex.com>" stdout
'
test_expect_success $PREREQ '--no-bcc overrides sendemail.bcc' '
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--no-bcc \
--bcc=bodies@example.com \
--to=nobody@example.com \
--smtp-server relay.example.com \
$patches >stdout &&
grep "RCPT TO:<bodies@example.com>" stdout &&
! grep "RCPT TO:<other@ex.com>" stdout
'
test_expect_success $PREREQ 'patches To headers are used by default' '
patch=$(git format-patch -1 --to="bodies@example.com") &&
test_when_finished "rm $patch" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--smtp-server relay.example.com \
$patch >stdout &&
grep "RCPT TO:<bodies@example.com>" stdout
'
test_expect_success $PREREQ 'patches To headers are appended to' '
patch=$(git format-patch -1 --to="bodies@example.com") &&
test_when_finished "rm $patch" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server relay.example.com \
$patch >stdout &&
grep "RCPT TO:<bodies@example.com>" stdout &&
grep "RCPT TO:<nobody@example.com>" stdout
'
test_expect_success $PREREQ 'To headers from files reset each patch' '
patch1=$(git format-patch -1 --to="bodies@example.com") &&
patch2=$(git format-patch -1 --to="other@example.com" HEAD~) &&
test_when_finished "rm $patch1 && rm $patch2" &&
git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to="nobody@example.com" \
--smtp-server relay.example.com \
$patch1 $patch2 >stdout &&
test $(grep -c "RCPT TO:<bodies@example.com>" stdout) = 1 &&
test $(grep -c "RCPT TO:<nobody@example.com>" stdout) = 2 &&
test $(grep -c "RCPT TO:<other@example.com>" stdout) = 1
'
test_expect_success $PREREQ 'setup expect' '
cat >email-using-8bit <<\EOF
From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
Message-Id: <bogus-message-id@example.com>
From: author@example.com
Date: Sat, 12 Jun 2010 15:53:58 +0200
Subject: subject goes here
Dieser deutsche Text enthält einen Umlaut!
EOF
'
test_expect_success $PREREQ 'setup expect' '
echo "Subject: subject goes here" >expected
'
test_expect_success $PREREQ 'ASCII subject is not RFC2047 quoted' '
clean_fake_sendmail &&
echo bogus |
git send-email --from=author@example.com --to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
grep "Subject" msgtxt1 >actual &&
test_cmp expected actual
'
test_expect_success $PREREQ 'setup expect' '
cat >content-type-decl <<-\EOF
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
EOF
'
test_expect_success $PREREQ 'asks about and fixes 8bit encodings' '
clean_fake_sendmail &&
echo |
git send-email --from=author@example.com --to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit >stdout &&
grep "do not declare a Content-Transfer-Encoding" stdout &&
grep email-using-8bit stdout &&
grep "Which 8bit encoding" stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
test_cmp content-type-decl actual
'
test_expect_success $PREREQ 'sendemail.8bitEncoding works' '
clean_fake_sendmail &&
git config sendemail.assume8bitEncoding UTF-8 &&
echo bogus |
git send-email --from=author@example.com --to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit >stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
test_cmp content-type-decl actual
'
test_expect_success $PREREQ '--8bit-encoding overrides sendemail.8bitEncoding' '
clean_fake_sendmail &&
git config sendemail.assume8bitEncoding "bogus too" &&
echo bogus |
git send-email --from=author@example.com --to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
test_cmp content-type-decl actual
'
test_expect_success $PREREQ 'setup expect' '
cat >email-using-8bit <<-\EOF
From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
Message-Id: <bogus-message-id@example.com>
From: author@example.com
Date: Sat, 12 Jun 2010 15:53:58 +0200
Subject: Dieser Betreff enthält auch einen Umlaut!
Nothing to see here.
EOF
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
Subject: =?UTF-8?q?Dieser=20Betreff=20enth=C3=A4lt=20auch=20einen=20Umlaut!?=
EOF
'
test_expect_success $PREREQ '--8bit-encoding also treats subject' '
clean_fake_sendmail &&
echo bogus |
git send-email --from=author@example.com --to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
grep "Subject" msgtxt1 >actual &&
test_cmp expected actual
'
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_expect_success $PREREQ 'setup expect' '
cat >email-using-8bit <<-\EOF
From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
Message-Id: <bogus-message-id@example.com>
From: A U Thor <author@example.com>
Date: Sat, 12 Jun 2010 15:53:58 +0200
Content-Type: text/plain; charset=UTF-8
Subject: Nothing to see here.
Dieser Betreff enthält auch einen Umlaut!
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_expect_success $PREREQ '--transfer-encoding overrides sendemail.transferEncoding' '
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
clean_fake_sendmail &&
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_must_fail git -c sendemail.transferEncoding=8bit \
send-email \
--transfer-encoding=7bit \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit \
2>errors >out &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
grep "cannot send message as 7bit" errors &&
test -z "$(ls msgtxt*)"
'
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_expect_success $PREREQ 'sendemail.transferEncoding via config' '
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
clean_fake_sendmail &&
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_must_fail git -c sendemail.transferEncoding=7bit \
send-email \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit \
2>errors >out &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
grep "cannot send message as 7bit" errors &&
test -z "$(ls msgtxt*)"
'
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_expect_success $PREREQ 'sendemail.transferEncoding via cli' '
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
clean_fake_sendmail &&
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
test_must_fail git send-email \
--transfer-encoding=7bit \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit \
2>errors >out &&
send-email: fix broken transferEncoding tests 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-17 21:55:42 +02:00
grep "cannot send message as 7bit" errors &&
test -z "$(ls msgtxt*)"
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
Dieser Betreff enth=C3=A4lt auch einen Umlaut!
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ '8-bit and sendemail.transferencoding=quoted-printable' '
clean_fake_sendmail &&
git send-email \
--transfer-encoding=quoted-printable \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit \
2>errors >out &&
sed "1,/^$/d" msgtxt1 >actual &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_cmp expected actual
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
RGllc2VyIEJldHJlZmYgZW50aMOkbHQgYXVjaCBlaW5lbiBVbWxhdXQhCg==
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ '8-bit and sendemail.transferencoding=base64' '
clean_fake_sendmail &&
git send-email \
--transfer-encoding=base64 \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit \
2>errors >out &&
sed "1,/^$/d" msgtxt1 >actual &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_cmp expected actual
'
test_expect_success $PREREQ 'setup expect' '
cat >email-using-qp <<-\EOF
From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
Message-Id: <bogus-message-id@example.com>
From: A U Thor <author@example.com>
Date: Sat, 12 Jun 2010 15:53:58 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Subject: Nothing to see here.
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
Dieser Betreff enth=C3=A4lt auch einen Umlaut!
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ 'convert from quoted-printable to base64' '
clean_fake_sendmail &&
git send-email \
--transfer-encoding=base64 \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-qp \
2>errors >out &&
sed "1,/^$/d" msgtxt1 >actual &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_cmp expected actual
'
test_expect_success $PREREQ 'setup expect' "
tr -d '\\015' | tr '%' '\\015' >email-using-crlf <<EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
Message-Id: <bogus-message-id@example.com>
From: A U Thor <author@example.com>
Date: Sat, 12 Jun 2010 15:53:58 +0200
Content-Type: text/plain; charset=UTF-8
Subject: Nothing to see here.
Look, I have a CRLF and an = sign!%
EOF
"
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
Look, I have a CRLF and an =3D sign!=0D
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ 'CRLF and sendemail.transferencoding=quoted-printable' '
clean_fake_sendmail &&
git send-email \
--transfer-encoding=quoted-printable \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-crlf \
2>errors >out &&
sed "1,/^$/d" msgtxt1 >actual &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_cmp expected actual
'
test_expect_success $PREREQ 'setup expect' '
cat >expected <<-\EOF
TG9vaywgSSBoYXZlIGEgQ1JMRiBhbmQgYW4gPSBzaWduIQ0K
EOF
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
'
test_expect_success $PREREQ 'CRLF and sendemail.transferencoding=base64' '
clean_fake_sendmail &&
git send-email \
--transfer-encoding=base64 \
--smtp-server="$(pwd)/fake.sendmail" \
email-using-crlf \
2>errors >out &&
sed "1,/^$/d" msgtxt1 >actual &&
git-send-email: add --transfer-encoding option The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392 details problems when applying patches with "git am" in a repository with CRLF line endings. In the example in the thread, the repository originated from "git-svn" so it is not possible to use core.eol and friends on it. Right now, the best option is to use "git am --keep-cr". However, when a patch create new files, the patch application process will reject the new file because it finds a "/dev/null\r" string instead of "/dev/null". The problem is that SMTP transport is CRLF-unsafe. Sending a patch by email is the same as passing it through "dos2unix | unix2dos". The newly introduced CRLFs are normally transparent because git-am strips them. The keepcr=true setting preserves them, but it is mostly working by chance and it would be very problematic to have a "git am" workflow in a repository with mixed LF and CRLF line endings. The MIME solution to this is the quoted-printable transfer enconding. This is not something that we want to enable by default, since it makes received emails horrible to look at. However, it is a very good match for projects that store CRLF line endings in the repository. The only disadvantage of quoted-printable is that quoted-printable patches fail to apply if the maintainer uses "git am --keep-cr". This is because the decoded patch will have two carriage returns at the end of the line. Therefore, add support for base64 transfer encoding too, which makes received emails downright impossible to look at outside a MUA, but really just works. The patch covers all bases, including users that still live in the late 80s, by also providing a 7bit content transfer encoding that refuses to send emails with non-ASCII character in them. And finally, "8bit" will add a Content-Transfer-Encoding header but otherwise do nothing. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 15:00:27 +01:00
test_cmp expected actual
'
# Note that the patches in this test are deliberately out of order; we
# want to make sure it works even if the cover-letter is not in the
# first mail.
test_expect_success $PREREQ 'refusing to send cover letter template' '
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch --cover-letter -2 -o outdir &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0002-*.patch \
outdir/0000-*.patch \
outdir/0001-*.patch \
2>errors >out &&
grep "SUBJECT HERE" errors &&
test -z "$(ls msgtxt*)"
'
test_expect_success $PREREQ '--force sends cover letter template anyway' '
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch --cover-letter -2 -o outdir &&
git send-email \
--force \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0002-*.patch \
outdir/0000-*.patch \
outdir/0001-*.patch \
2>errors >out &&
! grep "SUBJECT HERE" errors &&
test -n "$(ls msgtxt*)"
'
test_cover_addresses () {
header="$1"
shift
clean_fake_sendmail &&
rm -fr outdir &&
git format-patch --cover-letter -2 -o outdir &&
cover=$(echo outdir/0000-*.patch) &&
mv $cover cover-to-edit.patch &&
perl -pe "s/^From:/$header: extra\@address.com\nFrom:/" cover-to-edit.patch >"$cover" &&
git send-email \
--force \
--from="Example <nobody@example.com>" \
--no-to --no-cc \
"$@" \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0000-*.patch \
outdir/0001-*.patch \
outdir/0002-*.patch \
2>errors >out &&
grep "^$header: extra@address.com" msgtxt1 >to1 &&
grep "^$header: extra@address.com" msgtxt2 >to2 &&
grep "^$header: extra@address.com" msgtxt3 >to3 &&
test_line_count = 1 to1 &&
test_line_count = 1 to2 &&
test_line_count = 1 to3
}
test_expect_success $PREREQ 'to-cover adds To to all mail' '
test_cover_addresses "To" --to-cover
'
test_expect_success $PREREQ 'cc-cover adds Cc to all mail' '
test_cover_addresses "Cc" --cc-cover
'
test_expect_success $PREREQ 'tocover adds To to all mail' '
test_config sendemail.tocover true &&
test_cover_addresses "To"
'
test_expect_success $PREREQ 'cccover adds Cc to all mail' '
test_config sendemail.cccover true &&
test_cover_addresses "Cc"
'
test_expect_success $PREREQ 'escaped quotes in sendemail.aliasfiletype=mutt' '
clean_fake_sendmail &&
echo "alias sbd \\\"Dot U. Sir\\\" <somebody@example.org>" >.mutt &&
git config --replace-all sendemail.aliasesfile "$(pwd)/.mutt" &&
git config sendemail.aliasfiletype mutt &&
git send-email \
--from="Example <nobody@example.com>" \
--to=sbd \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0001-*.patch \
2>errors >out &&
grep "^!somebody@example\.org!$" commandline1 &&
grep -F "To: \"Dot U. Sir\" <somebody@example.org>" out
'
send-email: Fix %config_path_settings handling cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14 22:53:31 +02:00
test_expect_success $PREREQ 'sendemail.aliasfiletype=mailrc' '
clean_fake_sendmail &&
echo "alias sbd somebody@example.org" >.mailrc &&
git config --replace-all sendemail.aliasesfile "$(pwd)/.mailrc" &&
git config sendemail.aliasfiletype mailrc &&
git send-email \
--from="Example <nobody@example.com>" \
--to=sbd \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0001-*.patch \
2>errors >out &&
send-email: Fix %config_path_settings handling cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14 22:53:31 +02:00
grep "^!somebody@example\.org!$" commandline1
'
test_expect_success $PREREQ 'sendemail.aliasfile=~/.mailrc' '
clean_fake_sendmail &&
echo "alias sbd someone@example.org" >"$HOME/.mailrc" &&
send-email: Fix %config_path_settings handling cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14 22:53:31 +02:00
git config --replace-all sendemail.aliasesfile "~/.mailrc" &&
git config sendemail.aliasfiletype mailrc &&
git send-email \
--from="Example <nobody@example.com>" \
--to=sbd \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0001-*.patch \
2>errors >out &&
send-email: Fix %config_path_settings handling cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) broke the expansion of aliases. This was caused by treating %config_path_settings, newly introduced in said patch, like %config_bool_settings instead of like %config_settings. Copy from %config_settings, making it more readable. While at it add basic test for expansion of aliases, and for path expansion, which would catch this error. Nb. there were a few issues that were responsible for this error: 1. %config_bool_settings and %config_settings despite similar name have different semantic. %config_bool_settings values are arrays where the first element is (reference to) the variable to set, and second element is default value... which admittedly is a bit cryptic. More readable if more verbose option would be to use hash reference, e.g.: my %config_bool_settings = ( "thread" => { variable => \$thread, default => 1}, [...] %config_settings values are either either reference to scalar variable or reference to array. In second case it means that option (or config option) is multi-valued. BTW. this is similar to what Getopt::Long does. 2. In cec5dae (use new Git::config_path() for aliasesfile, 2011-09-30) the setting "aliasesfile" was moved from %config_settings to newly introduced %config_path_settings. But the loop that parses settings from %config_path_settings was copy'n'pasted *wrongly* from %config_bool_settings instead of from %config_settings. It looks like cec5dae author cargo-culted this change... 3. 994d6c6 (send-email: address expansion for common mailers, 2006-05-14) didn't add test for alias expansion to t9001-send-email.sh Signed-off-by: Cord Seele <cowose@gmail.com> Tested-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14 22:53:31 +02:00
grep "^!someone@example\.org!$" commandline1
'
test_dump_aliases () {
msg="$1" && shift &&
filetype="$1" && shift &&
printf '%s\n' "$@" >expect &&
cat >.tmp-email-aliases &&
test_expect_success $PREREQ "$msg" '
clean_fake_sendmail && rm -fr outdir &&
git config --replace-all sendemail.aliasesfile \
"$(pwd)/.tmp-email-aliases" &&
git config sendemail.aliasfiletype "$filetype" &&
git send-email --dump-aliases 2>errors >actual &&
test_cmp expect actual
'
}
test_dump_aliases '--dump-aliases sendmail format' \
'sendmail' \
'abgroup' \
'alice' \
'bcgrp' \
'bob' \
'chloe' <<-\EOF
alice: Alice W Land <awol@example.com>
bob: Robert Bobbyton <bob@example.com>
chloe: chloe@example.com
abgroup: alice, bob
bcgrp: bob, chloe, Other <o@example.com>
EOF
test_dump_aliases '--dump-aliases mutt format' \
'mutt' \
'alice' \
'bob' \
'chloe' \
'donald' <<-\EOF
alias alice Alice W Land <awol@example.com>
alias donald Donald C Carlton <donc@example.com>
alias bob Robert Bobbyton <bob@example.com>
alias chloe chloe@example.com
EOF
test_dump_aliases '--dump-aliases mailrc format' \
'mailrc' \
'alice' \
'bob' \
'chloe' \
'eve' <<-\EOF
alias alice Alice W Land <awol@example.com>
alias eve Eve <eve@example.com>
alias bob Robert Bobbyton <bob@example.com>
alias chloe chloe@example.com
EOF
test_dump_aliases '--dump-aliases pine format' \
'pine' \
'alice' \
'bob' \
'chloe' \
'eve' <<-\EOF
alice Alice W Land <awol@example.com>
eve Eve <eve@example.com>
bob Robert Bobbyton <bob@example.com>
chloe chloe@example.com
EOF
test_dump_aliases '--dump-aliases gnus format' \
'gnus' \
'alice' \
'bob' \
'chloe' \
'eve' <<-\EOF
(define-mail-alias "alice" "awol@example.com")
(define-mail-alias "eve" "eve@example.com")
(define-mail-alias "bob" "bob@example.com")
(define-mail-alias "chloe" "chloe@example.com")
EOF
test_expect_success '--dump-aliases must be used alone' '
test_must_fail git send-email --dump-aliases --to=janice@example.com -1 refs/heads/accounting
'
send-email: fix regression in sendemail.identity parsing 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-17 21:55:44 +02:00
test_expect_success $PREREQ 'aliases and sendemail.identity' '
test_must_fail git \
-c sendemail.identity=cloud \
-c sendemail.aliasesfile=default-aliases \
-c sendemail.cloud.aliasesfile=cloud-aliases \
send-email -1 2>stderr &&
test_i18ngrep "cloud-aliases" stderr
'
test_sendmail_aliases () {
msg="$1" && shift &&
expect="$@" &&
cat >.tmp-email-aliases &&
test_expect_success $PREREQ "$msg" '
clean_fake_sendmail && rm -fr outdir &&
git format-patch -1 -o outdir &&
git config --replace-all sendemail.aliasesfile \
"$(pwd)/.tmp-email-aliases" &&
git config sendemail.aliasfiletype sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=alice --to=bcgrp \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/0001-*.patch \
2>errors >out &&
for i in $expect
do
grep "^!$i!$" commandline1 || return 1
done
'
}
test_sendmail_aliases 'sendemail.aliasfiletype=sendmail' \
'awol@example\.com' \
'bob@example\.com' \
'chloe@example\.com' \
'o@example\.com' <<-\EOF
alice: Alice W Land <awol@example.com>
bob: Robert Bobbyton <bob@example.com>
# this is a comment
# this is also a comment
chloe: chloe@example.com
abgroup: alice, bob
bcgrp: bob, chloe, Other <o@example.com>
EOF
test_sendmail_aliases 'sendmail aliases line folding' \
alice1 \
bob1 bob2 \
chuck1 chuck2 \
darla1 darla2 darla3 \
elton1 elton2 elton3 \
fred1 fred2 \
greg1 <<-\EOF
alice: alice1
bob: bob1,\
bob2
chuck: chuck1,
chuck2
darla: darla1,\
darla2,
darla3
elton: elton1,
elton2,\
elton3
fred: fred1,\
fred2
greg: greg1
bcgrp: bob, chuck, darla, elton, fred, greg
EOF
test_sendmail_aliases 'sendmail aliases tolerate bogus line folding' \
alice1 bob1 <<-\EOF
alice: alice1
bcgrp: bob1\
EOF
test_sendmail_aliases 'sendmail aliases empty' alice bcgrp <<-\EOF
EOF
test_expect_success $PREREQ 'alias support in To header' '
clean_fake_sendmail &&
echo "alias sbd someone@example.org" >.mailrc &&
test_config sendemail.aliasesfile ".mailrc" &&
test_config sendemail.aliasfiletype mailrc &&
git format-patch --stdout -1 --to=sbd >aliased.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
aliased.patch \
2>errors >out &&
grep "^!someone@example\.org!$" commandline1
'
test_expect_success $PREREQ 'alias support in Cc header' '
clean_fake_sendmail &&
echo "alias sbd someone@example.org" >.mailrc &&
test_config sendemail.aliasesfile ".mailrc" &&
test_config sendemail.aliasfiletype mailrc &&
git format-patch --stdout -1 --cc=sbd >aliased.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
aliased.patch \
2>errors >out &&
grep "^!someone@example\.org!$" commandline1
'
test_expect_success $PREREQ 'tocmd works with aliases' '
clean_fake_sendmail &&
echo "alias sbd someone@example.org" >.mailrc &&
test_config sendemail.aliasesfile ".mailrc" &&
test_config sendemail.aliasfiletype mailrc &&
git format-patch --stdout -1 >tocmd.patch &&
echo tocmd--sbd >>tocmd.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--to-cmd=./tocmd-sed \
--smtp-server="$(pwd)/fake.sendmail" \
tocmd.patch \
2>errors >out &&
grep "^!someone@example\.org!$" commandline1
'
test_expect_success $PREREQ 'cccmd works with aliases' '
clean_fake_sendmail &&
echo "alias sbd someone@example.org" >.mailrc &&
test_config sendemail.aliasesfile ".mailrc" &&
test_config sendemail.aliasfiletype mailrc &&
git format-patch --stdout -1 >cccmd.patch &&
echo cccmd--sbd >>cccmd.patch &&
git send-email \
--from="Example <nobody@example.com>" \
--cc-cmd=./cccmd-sed \
--smtp-server="$(pwd)/fake.sendmail" \
cccmd.patch \
2>errors >out &&
grep "^!someone@example\.org!$" commandline1
'
do_xmailer_test () {
expected=$1 params=$2 &&
git format-patch -1 &&
git send-email \
--from="Example <nobody@example.com>" \
--to=someone@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
$params \
0001-*.patch \
2>errors >out &&
{ grep '^X-Mailer:' out || :; } >mailer &&
test_line_count = $expected mailer
}
test_expect_success $PREREQ '--[no-]xmailer without any configuration' '
do_xmailer_test 1 "--xmailer" &&
do_xmailer_test 0 "--no-xmailer"
'
test_expect_success $PREREQ '--[no-]xmailer with sendemail.xmailer=true' '
test_config sendemail.xmailer true &&
do_xmailer_test 1 "" &&
do_xmailer_test 0 "--no-xmailer" &&
do_xmailer_test 1 "--xmailer"
'
test_expect_success $PREREQ '--[no-]xmailer with sendemail.xmailer=false' '
test_config sendemail.xmailer false &&
do_xmailer_test 0 "" &&
do_xmailer_test 0 "--no-xmailer" &&
do_xmailer_test 1 "--xmailer"
'
test_expect_success $PREREQ 'setup expected-list' '
git send-email \
--dry-run \
--from="Example <from@example.com>" \
--to="To 1 <to1@example.com>" \
--to="to2@example.com" \
--to="to3@example.com" \
--cc="Cc 1 <cc1@example.com>" \
--cc="Cc2 <cc2@example.com>" \
--bcc="bcc1@example.com" \
--bcc="bcc2@example.com" \
0001-add-main.patch | replace_variable_fields \
>expected-list
'
test_expect_success $PREREQ 'use email list in --cc --to and --bcc' '
git send-email \
--dry-run \
--from="Example <from@example.com>" \
--to="To 1 <to1@example.com>, to2@example.com" \
--to="to3@example.com" \
--cc="Cc 1 <cc1@example.com>, Cc2 <cc2@example.com>" \
--bcc="bcc1@example.com, bcc2@example.com" \
0001-add-main.patch | replace_variable_fields \
>actual-list &&
test_cmp expected-list actual-list
'
test_expect_success $PREREQ 'aliases work with email list' '
echo "alias to2 to2@example.com" >.mutt &&
echo "alias cc1 Cc 1 <cc1@example.com>" >>.mutt &&
test_config sendemail.aliasesfile ".mutt" &&
test_config sendemail.aliasfiletype mutt &&
git send-email \
--dry-run \
--from="Example <from@example.com>" \
--to="To 1 <to1@example.com>, to2, to3@example.com" \
--cc="cc1, Cc2 <cc2@example.com>" \
--bcc="bcc1@example.com, bcc2@example.com" \
0001-add-main.patch | replace_variable_fields \
>actual-list &&
test_cmp expected-list actual-list
'
test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
echo "alias to2 to2@example.com" >.mutt &&
echo "alias cc1 Cc 1 <cc1@example.com>" >>.mutt &&
test_config sendemail.aliasesfile ".mutt" &&
test_config sendemail.aliasfiletype mutt &&
TO1=$(echo "QTo 1 <to1@example.com>" | q_to_tab) &&
TO2=$(echo "QZto2" | qz_to_tab_space) &&
CC1=$(echo "cc1" | append_cr) &&
BCC1=$(echo " bcc1@example.com Q" | q_to_nul) &&
git send-email \
--dry-run \
--from=" Example <from@example.com>" \
--to="$TO1" \
--to="$TO2" \
--to=" to3@example.com " \
--cc="$CC1" \
--cc="Cc2 <cc2@example.com>" \
--bcc="$BCC1" \
--bcc="bcc2@example.com" \
0001-add-main.patch | replace_variable_fields \
>actual-list &&
test_cmp expected-list actual-list
'
test_expect_success $PREREQ 'invoke hook' '
mkdir -p .git/hooks &&
write_script .git/hooks/sendemail-validate <<-\EOF &&
# test that we have the correct environment variable, pwd, and
# argument
case "$GIT_DIR" in
*.git)
true
;;
*)
false
;;
esac &&
test -f 0001-add-main.patch &&
grep "add main" "$1"
EOF
mkdir subdir &&
(
# Test that it works even if we are not at the root of the
# working tree
cd subdir &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/../fake.sendmail" \
../0001-add-main.patch &&
# Verify error message when a patch is rejected by the hook
sed -e "s/add main/x/" ../0001-add-main.patch >../another.patch &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/../fake.sendmail" \
../another.patch 2>err &&
test_i18ngrep "rejected by sendemail-validate hook" err
)
'
test_expect_success $PREREQ 'test that send-email works outside a repo' '
nongit git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
"$(pwd)/0001-add-main.patch"
'
test_expect_success $PREREQ 'test that sendmail config is rejected' '
test_config sendmail.program sendmail &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
HEAD^ 2>err &&
test_i18ngrep "found configuration options for '"'"sendmail"'"'" err
'
test_expect_success $PREREQ 'test that sendmail config rejection is specific' '
test_config resendmail.program sendmail &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
HEAD^
'
test_expect_success $PREREQ 'test forbidSendmailVariables behavior override' '
test_config sendmail.program sendmail &&
test_config sendemail.forbidSendmailVariables false &&
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
HEAD^
'
test_done