summaryrefslogtreecommitdiff
path: root/t/t9001-send-email.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-10-28tests: undo special treatment of CRLF for WindowsLibravatar Johannes Sixt1-1/+0
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-0/+14
Logic used by git-send-email to suppress cc mishandled names that need RFC2047 quoting. * mt/send-email-cc-match-fix: send-email: sanitize author when writing From line send-email: add test for duplicate utf8 name
2013-06-20send-email: sanitize author when writing From lineLibravatar Michael S. Tsirkin1-1/+1
sender is now sanitized, but we didn't sanitize author when checking whether From: line is needed in the message body. As a result git started writing duplicate From: lines when author matched sender and has utf8 characters. Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-20send-email: add test for duplicate utf8 nameLibravatar Michael S. Tsirkin1-0/+14
Verify that author name is not duplicated if it matches sender, even if it is in utf8 (the test expects a failure that will be fixed in the next patch). Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14Merge branch 'mt/send-email-cc-match-fix'Libravatar Junio C Hamano1-0/+75
Logic git-send-email used to suppress cc mishandled names like "A U. Thor" <author@example.xz>, where the human readable part needs to be quoted (the user input may not have the double quotes around the name, and comparison was done between quoted and unquoted strings). * mt/send-email-cc-match-fix: test-send-email: test for pre-sanitized self name t/send-email: test suppress-cc=self with non-ascii t/send-email: add test with quoted sender send-email: make --suppress-cc=self sanitize input t/send-email: test suppress-cc=self on cccmd send-email: fix suppress-cc=self on cccmd t/send-email.sh: add test for suppress-cc=self
2013-06-05test-send-email: test for pre-sanitized self nameLibravatar Michael S. Tsirkin1-0/+5
Users can sanitize from address manually. Verify that these are suppressed properly. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05t/send-email: test suppress-cc=self with non-asciiLibravatar Michael S. Tsirkin1-0/+5
test suppress-cc=self when sender is non-acsii Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05t/send-email: add test with quoted senderLibravatar Michael S. Tsirkin1-0/+20
add test where sender address needs to be quoted. Make sure --suppress-cc=self works well in this case. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05t/send-email: test suppress-cc=self on cccmdLibravatar Michael S. Tsirkin1-1/+3
Check that suppress-cc=self works when applied to output of cccmd. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-03t/send-email.sh: add test for suppress-cc=selfLibravatar Michael S. Tsirkin1-0/+43
This adds a basic test for --suppress-cc=self option of git send-email. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-28send-email: remove warning about unset chainreplytoLibravatar Felipe Contreras1-49/+0
Three years and a half is probably more than enough time to give users the opportunity to configure Git to do what they want. If they haven't changed the configuration by now, this warning message is not going to do anything for them anyway. This effectively reverts commit 528fb08 (prepare send-email for smoother change of --chain-reply-to default). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-2/+2
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-28t9001: check send-email behavior with implicit senderLibravatar Jeff King1-0/+28
We allow send-email to use an implicitly-defined identity for the sender (because there is still a confirmation step), but we abort when we cannot generate such an identity. Let's make sure that we test this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-26send-email: avoid questions when user has an identLibravatar Felipe Contreras1-3/+2
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-10-25git-send-email: skip RFC2047 quoting for ASCII subjectsLibravatar Krzysztof Mazur1-0/+17
The git-send-email always use RFC2047 subject quoting for files with "broken" encoding - non-ASCII files without Content-Transfer-Encoding, even for ASCII subjects. This is harmless but unnecessarily ugly for people reading the raw headers. This patch skips rfc2047 quoting when the subject does not need it. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-send-email: use compose-encoding for SubjectLibravatar Krzysztof Mazur1-0/+14
The commit "git-send-email: introduce compose-encoding" introduced the compose-encoding option to specify the introduction email encoding (--compose option), but the email Subject encoding was still hardcoded to UTF-8. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Jeff King <peff@peff.net>
2012-10-10git-send-email: introduce compose-encodingLibravatar Krzysztof Mazur1-0/+55
The introduction email (--compose option) have encoding hardcoded to UTF-8, but invoked editor may not use UTF-8 encoding. The encoding used by patches can be changed by the "8bit-encoding" option, but this option does not have effect on introduction email and equivalent for introduction email is missing. Added compose-encoding command line option and sendemail.composeencoding configuration option specify encoding of introduction email. Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-31send-email: improve RFC2047 quote parsingLibravatar Thomas Rast1-0/+13
The RFC2047 unquoting, used to parse email addresses in From and Cc headers, is broken in several ways: * It erroneously substitutes ' ' for '_' in *the whole* header, even outside the quoted field. [Noticed by Christoph.] * It is too liberal in its matching, and happily matches the start of one quoted chunk against the end of another, or even just something that looks like such an end. [Noticed by Junio.] * It fundamentally cannot cope with encodings that are not a superset of ASCII, nor several (incompatible) encodings in the same header. This patch fixes the first two by doing a more careful decoding of the outer quoting (e.g. "=AB" to represent an octet whose value is 0xAB). Fixing the fundamental issues is left for a future, more intrusive, patch. Noticed-by: Christoph Miebach <christoph.miebach@web.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14t9001: do not fail only due to CR/LF issuesLibravatar Johannes Schindelin1-0/+1
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-14send-email: Fix %config_path_settings handlingLibravatar Cord Seele1-0/+28
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-01-05Merge branch 'ao/t9001-fix'Libravatar Junio C Hamano1-4/+4
* ao/t9001-fix: t/t9001-send-email.sh: fix '&&' chain in some tests
2011-01-04t/t9001-send-email.sh: fix '&&' chain in some testsLibravatar Antonio Ospite1-4/+4
t/README recommends chaining test assertions. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-04Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: gitweb: skip logo in atom feed when there is none t9001: Fix test prerequisites
2010-12-29t9001: Fix test prerequisitesLibravatar Robin H. Johnson1-2/+2
Add in missing Perl prerequisites for new tests of send-email. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-28t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'Libravatar Brandon Casey1-1/+1
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The '--no-' prefix (as in --no-chain-reply-to) for boolean options is not supported in Getopt::Long version 2.32 which was released with Perl 5.8.0. This version only supports '--no' as in '--nochain-reply-to'. More recent versions of Getopt::Long, such as version 2.34, support either prefix. So use the older form in the tests. See also: 907a0b1e04ea31cb368e9422df93d8ebb0187914 84eeb687de7a6c7c42af3fb51b176e0f412a979e 3fee1fe87144360a1913eab86af9ad136c810076 Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter' into maintLibravatar Junio C Hamano1-0/+36
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-11-12git-send-email.perl: make initial In-Reply-To apply only to first emailLibravatar Antonio Ospite1-1/+3
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-05t9001: send-email interation with --in-reply-to and --chain-reply-toLibravatar Junio C Hamano1-0/+41
1. When --in-reply-to gives $reply_to, the first one becomes a reply to that message, with or without --chain-reply-to. 2. When --chain-reply-to is in effect, all the messages are strung together to form a single chain. The first message may be in reply to the $reply_to given by --in-reply-to command line option (see previous), or the root of the discussion thread. The second one is a response to the first one, and the third one is a response to the second one, etc. 3. When --chain-reply-to is not in effect: a. When --in-reply-to is used, too, the second and the subsequent ones become replies to $reply_to. Together with the first rule, all messages become replies to $reply_to given by --in-reply-to. b. When --in-reply-to is not used, presumably the second and subsequent ones become replies to the first one, which would be the root. The documentation is reasonably clear about the 1., 2. and 3a. above, I think, even though I do not think 3b. is clearly specified. The two tests added by this patch at least documents what happens between these two options. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-26Merge branch 'ab/send-email-perl'Libravatar Junio C Hamano1-1/+1
* ab/send-email-perl: send-email: extract_valid_address use qr// regexes send-email: is_rfc2047_quoted use qr// regexes send-email: use Perl idioms in while loop send-email: make_message_id use "require" instead of "use" send-email: send_message die on $!, not $? send-email: use (?:) instead of () if no match variables are needed send-email: sanitize_address use qq["foo"], not "\"foo\"" send-email: sanitize_address use $foo, not "$foo" send-email: use \E***\Q instead of \*\*\* send-email: cleanup_compose_files doesn't need a prototype send-email: unique_email_list doesn't need a prototype send-email: file_declares_8bit_cte doesn't need a prototype send-email: get_patch_subject doesn't need a prototype send-email: use lexical filehandles during sending send-email: use lexical filehandles for $compose send-email: use lexical filehandle for opendir Conflicts: git-send-email.perl
2010-10-26Merge branch 'sb/send-email-use-to-from-input'Libravatar Junio C Hamano1-0/+39
* sb/send-email-use-to-from-input: send-email: Don't leak To: headers between patches send-email: Use To: headers in patch files Conflicts: git-send-email.perl
2010-10-26Merge branch 'jp/send-email-to-cmd'Libravatar Junio C Hamano1-0/+18
* jp/send-email-to-cmd: git-send-email.perl: Add --to-cmd Conflicts: git-send-email.perl
2010-10-19Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To' Clarify and extend the "git diff" format documentation git-show-ref.txt: clarify the pattern matching documentation: git-config minor cleanups Update test script annotate-tests.sh to handle missing/extra authors
2010-10-19t/t9001-send-email.sh: fix stderr redirection in 'Invalid In-Reply-To'Libravatar Antonio Ospite1-1/+1
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-04send-email: Don't leak To: headers between patchesLibravatar Stephen Boyd1-0/+15
If the first patch in a series has a To: header in the file and the second patch in the series doesn't the address from the first patch will be part of the To: addresses in the second patch. Fix this by treating the to list like the cc list. Have an initial to list come from the command line, user input and config options. Then build up a to list from each patch and concatenate the two together before sending the patch. Finally, reset the list after sending each patch so the To: headers from a patch don't get used for the next one. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-30send-email: use Perl idioms in while loopLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change `while(<$fh>) { my $c = $_' to `while(my $c = <$fh>) {', and use `chomp $c' instead of `$c =~ s/\n$//g;', the two are equivalent in this case. I've also changed the --cccmd test so that we test for the stripping of whitespace at the beginning of the lines returned from the --cccmd. I think we probably shouldn't do this, but it was there already so I haven't changed the behavior. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.comReviewed-by: Avery Pennarun <apenwarr@gmail.com> Reviewed-by: Jeff King <peff@peff.net> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29Merge branch 'tr/send-email-refuse-sending-unedited-cover-letter'Libravatar Junio C Hamano1-0/+36
* tr/send-email-refuse-sending-unedited-cover-letter: send-email: Refuse to send cover-letter template subject
2010-09-29send-email: Use To: headers in patch filesLibravatar Stephen Boyd1-0/+24
It's a minor annoyance when you take the painstaking time to setup To: headers for each patch in a large series, and then go out to send the series with git-send-email and watch git ignore the To: headers in the patch files. Therefore, always add To: headers from a patch file to the To: headers for that message. Keep the prompt for the blanket To: header so as to not break scripts (and user expectations). This means even if a patch has a To: header, git will prompt for the To: address. Otherwise, we'll need to introduce interface breakage to either request the header for each patch missing a To: header or default the header to whatever To: address is found first (be it in a patch or from user input). Both of these options don't seem very obvious/useful. Reported-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Tested-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-27git-send-email.perl: Add --to-cmdLibravatar Joe Perches1-0/+18
Add the ability to use a command line --to-cmd=cmd to create the list of "To:" addresses. Used a shared routine for --cc-cmd and --to-cmd. Did not use IPC::Open2, leaving that for Ævar if ever he decides to fix the other bugs he might find. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-08send-email: Refuse to send cover-letter template subjectLibravatar Thomas Rast1-0/+36
Every so often, someone sends out an unedited cover-letter template. Add a simple check to send-email that refuses to send if the subject contains "*** SUBJECT HERE ***", with an option --force to override. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t/t9001-send-email.sh: convert setup code to testsLibravatar Ævar Arnfjörð Bjarmason1-3/+40
Change the setup code in t/t9001-send-email.sh to use test_expect_success. This way it isn't needlessly run in environments where the test prerequisites aren't met. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t/t9001-send-email.sh: change from skip_all=* to prereq skipLibravatar Ævar Arnfjörð Bjarmason1-82/+83
Change this test to skip test with test prerequisites, and to do setup work in tests. This improves the skipped statistics on platforms where the test isn't run. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18t/t9001-send-email.sh: Remove needless PROG=* assignmentLibravatar Ævar Arnfjörð Bjarmason1-1/+0
Remove the PROG=* assignment from t9001-send-email.sh. It's been there since v1.4.0-rc1~30 when the test was originally added, but only tests that source annotate-tests.sh need it, it was seemingly introduced to this test via copy/paste coding. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07Merge branch 'ab/tap'Libravatar Junio C Hamano1-2/+2
* ab/tap: t/README: document more test helpers t/README: proposed rewording... t/README: Document the do's and don'ts of tests t/README: Add a section about skipping tests t/README: Document test_expect_code t/README: Document test_external* t/README: Document the prereq functions, and 3-arg test_* t/README: Typo: paralell -> parallel t/README: The trash is in 't/trash directory.$name' t/t9700/test.pl: don't access private object members, use public access methods t9700: Use Test::More->builder, not $Test::Builder::Test tests: Say "pass" rather than "ok" on empty lines for TAP tests: Skip tests in a way that makes sense under TAP test-lib: output a newline before "ok" under a TAP harness test-lib: Make the test_external_* functions TAP-aware test-lib: Adjust output to be valid TAP format
2010-06-29t/t9001: use egrep when regular expressions are involvedLibravatar Brandon Casey1-3/+3
Supplying backslashed, extended regular expressions to grep is not portable. Use egrep instead. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25tests: Skip tests in a way that makes sense under TAPLibravatar Ævar Arnfjörð Bjarmason1-2/+2
SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-18send-email: ask about and declare 8bit mailsLibravatar Thomas Rast1-0/+77
git-send-email passes on an 8bit mail as-is even if it does not declare a content-type. Because the user can edit email between format-patch and send-email, such invalid mails are unfortunately not very hard to come by. Make git-send-email stop and ask about the encoding to use if it encounters any such mail. Also provide a configuration setting to permanently configure an encoding. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-08send-email: add --no-cc, --no-to, and --no-bccLibravatar Stephen Boyd1-0/+66
There's no way to override the sendemail.to, sendemail.cc, and sendemail.bcc config settings. Add options allowing the user to tell git to ignore the config settings and take whatever is on the command line. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26fix portability issues with $ in double quotesLibravatar Stephen Boyd1-4/+4
Using a dollar sign in double quotes isn't portable. Escape them with a backslash or replace the double quotes with single quotes. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-03t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'Libravatar Brandon Casey1-1/+1
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The '--no-' prefix (as in --no-chain-reply-to) for boolean options is not supported in Getopt::Long version 2.32 which was released with Perl 5.8.0. This version only supports '--no' as in '--nochain-reply-to'. More recent versions of Getopt::Long, such as version 2.34, support either prefix. So use the older form in the tests. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-30Merge branch 'fc/send-email-envelope'Libravatar Junio C Hamano1-0/+34