summaryrefslogtreecommitdiff
path: root/t/t5100-mailinfo.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-12-13t5000-t5999: detect and signal failure within loopLibravatar Eric Sunshine1-1/+1
Failures within `for` and `while` loops can go unnoticed if not detected and signaled manually since the loop itself does not abort when a contained command fails, nor will a failure necessarily be detected when the loop finishes since the loop returns the exit code of the last command it ran on the final iteration, which may not be the command which failed. Therefore, detect and signal failures manually within loops using the idiom `|| return 1` (or `|| exit 1` within subshells). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: allow stripping quoted CR without warningLibravatar Đoàn Trần Công Danh1-0/+6
In previous changes, we've turned on warning for quoted CR in base64 or quoted-printable email messages. Some projects see those quoted CR a lot, they know that it happens most of the time, and they find it's desirable to always strip those CR. Those projects in question usually fall back to use other tools to handle patches when receive such patches. Let's help those projects handle those patches by stripping those excessive CR. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: allow squelching quoted CRLF warningLibravatar Đoàn Trần Công Danh1-1/+5
In previous change, Git starts to warn for quoted CRLF in decoded base64/QP email. Despite those warnings are usually helpful, quoted CRLF could be part of some users' workflow. Let's give them an option to turn off the warning completely. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10mailinfo: warn if CRLF found in decoded base64/QP emailLibravatar Đoàn Trần Công Danh1-0/+30
When SMTP servers receive 8-bit email messages, possibly with only LF as line ending, some of them decide to change said LF to CRLF. Some mailing list softwares, when receive 8-bit email messages, decide to encode those messages in base64 or quoted-printable. If an email is transfered through above mail servers, then distributed by such mailing list softwares, the recipients will receive an email contains a patch mungled with CRLF encoded inside another encoding. Thus, such CR (in CRLF) couldn't be dropped by "mailsplit". Hence, the mailed patch couldn't be applied cleanly. Such accidents have been observed in the wild [1]. Instead of silently rejecting those messages, let's give our users some warnings if such CR (as part of CRLF) is found. [1]: https://nmbug.notmuchmail.org/nmweb/show/m2lf9ejegj.fsf%40guru.guru-group.fi Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-11mailinfo: be more liberal with header whitespaceLibravatar Jeff King1-0/+15
RFC822 and friends allow arbitrary whitespace after the colon of a header and before the values. I.e.: Subject:foo Subject: foo Subject: foo all have the subject "foo". But mailinfo requires exactly one space. This doesn't seem to be bothering anybody, but it is pickier than the standard specifies. And we can easily just soak up arbitrary whitespace there in our parser, so let's do so. Note that the test covers both too little and too much whitespace, but the "too much" case already works fine (because we later eat leading and trailing whitespace from the values). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-22Merge branch 'km/test-mailinfo-b-failure'Libravatar Junio C Hamano1-0/+42
New tests. * km/test-mailinfo-b-failure: t5100: add some more mailinfo tests
2017-06-12t5100: add some more mailinfo testsLibravatar Kyle J. McKay1-0/+42
Add some more simple mailinfo tests including a few that produce: fatal: `pos + len' is too far after the end of the buffer Mark those as 'test_expect_failure'. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-22mailinfo: read local configurationLibravatar Junio C Hamano1-0/+13
Since b9605bc4f2 ("config: only read .git/config from configured repos", 2016-09-12), we do not read from ".git/config" unless we know we are in a repository. "git mailinfo" however didn't do the repository discovery and instead relied on the old behaviour. This was mostly OK because it was merely run as a helper program by other porcelain scripts that first chdir's up to the root of the working tree. Teach the command to run a "gentle" version of repository discovery so that local configuration variables like mailinfo.scissors are honoured. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-03Merge branch 'kd/mailinfo-quoted-string'Libravatar Junio C Hamano1-33/+49
An author name, that spelled a backslash-quoted double quote in the human readable part "My \"double quoted\" name", was not unquoted correctly while applying a patch from a piece of e-mail. * kd/mailinfo-quoted-string: mailinfo: unescape quoted-pair in header fields t5100-mailinfo: replace common path prefix with variable
2016-09-28mailinfo: unescape quoted-pair in header fieldsLibravatar Kevin Daudt1-0/+14
rfc2822 has provisions for quoted strings in structured header fields, but also allows for escaping these with so-called quoted-pairs. The only thing git currently does is removing exterior quotes, but quotes within are left alone. Remove exterior quotes and remove escape characters so that they don't show up in the author field. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-28t5100-mailinfo: replace common path prefix with variableLibravatar Kevin Daudt1-33/+35
Many tests need to store data in a file, and repeat the same pattern to refer to that path: "$TEST_DIRECTORY"/t5100/ Create a variable that contains this path, and use that instead. While we're making this change, make sure the quotes are not just around the variable, but around the entire string to not give the impression we want shell splitting to affect the other variables. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21mailinfo: handle in-body header continuationsLibravatar Jonathan Tan1-1/+1
Mailinfo currently handles multi-line headers, but it does not handle multi-line in-body headers. Teach it to handle such headers, for example, for this input: From: author <author@example.com> Date: Fri, 9 Jun 2006 00:44:16 -0700 Subject: a very long broken line Subject: another very long broken line interpret the in-body subject to be "another very long broken line" instead of "another very long". An existing test (t/t5100/msg0015) has an indented line immediately after an in-body header - it has been modified to reflect the new functionality. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06mailsplit: support unescaping mboxrd messagesLibravatar Eric Wong1-0/+31
This will allow us to parse the output of --pretty=mboxrd and the output of other mboxrd generators. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28t/t5100: no need to use 'echo' command substitutions for globbingLibravatar Johannes Sixt1-2/+2
Instead of making the shell expand 00* and invoke 'echo' with it, and then capturing its output as command substitution, just use the result of expanding 00* directly. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28t/t5100-mailinfo.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-6/+6
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix severe &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, in a location which causes a significant portion of the test to be missed (e.g., the test effectively does nothing, or consists of a long string of actions and output comparisons, and we throw away the exit code of at least one part of the string). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-mailinfo: add --message-idLibravatar Paolo Bonzini1-0/+4
This option adds the content of the Message-Id header at the end of the commit message prepared by git-mailinfo. This is useful in order to associate commit messages automatically with mailing list discussions. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-16mailinfo: make ">From" in-body header check more robustLibravatar Jeff King1-0/+18
Since commit 81c5cf7 (mailinfo: skip bogus UNIX From line inside body, 2006-05-21), we have treated lines like ">From" in the body as headers. This makes "git am" work for people who erroneously paste the whole output from format-patch: From 12345abcd...fedcba543210 Mon Sep 17 00:00:00 2001 From: them Subject: [PATCH] whatever into their email body (assuming that an mbox writer then quotes "From" as ">From", as otherwise we would actually mailsplit on the in-body line). However, this has false positives if somebody actually has a commit body that starts with "From "; in this case we erroneously remove the line entirely from the commit message. We can make this check more robust by making sure the line actually looks like a real mbox "From" line. Inspect the line that begins with ">From " a more carefully to only skip lines that match the expected pattern (note that the datestamp part of the format-patch output is designed to be kept constant to help those who write magic(5) entries). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17mailinfo: do not concatenate charset= attribute values from mime headersLibravatar Junio C Hamano1-1/+1
"Content-type: text/plain; charset=UTF-8" header should not appear twice in the input, but it is always better to gracefully deal with such a case. The current code concatenates the value to the values we have seen previously, producing nonsense such as "utf8UTF-8". Instead of concatenating, forget the previous value and use the last value we see. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11tests: modernise style: more uses of test_line_countLibravatar Stefano Lattarini1-1/+1
Prefer: test_line_count <OP> COUNT FILE over: test $(wc -l <FILE) <OP> COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20git am/mailinfo: Don't look at in-body headers when rebasingLibravatar Lukas Sandström1-1/+5
When we are rebasing we know that the header lines in the patch are good and that we don't need to pick up any headers from the body of the patch. This makes it possible to rebase commits whose commit message start with "From" or "Date". Test vectors by Jeff King. Signed-off-by: Lukas Sandström <luksan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-26am/mailinfo: Disable scissors processing by defaultLibravatar Junio C Hamano1-7/+15
You can enable it by giving --scissors to "git am". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-26Teach mailinfo to ignore everything before -- >8 -- markLibravatar Junio C Hamano1-1/+1
This teaches mailinfo the scissors -- >8 -- mark; the command ignores everything before it in the message body. For lefties among us, we also support -- 8< -- ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-31Merge branch 'ks/maint-mailinfo-folded'Libravatar Junio C Hamano1-1/+23
* ks/maint-mailinfo-folded: mailinfo: tests for RFC2047 examples mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)' mailinfo: 'From:' header should be unfold as well mailinfo: correctly handle multiline 'Subject:' header
2009-01-28mailinfo: tests for RFC2047 examplesLibravatar Kirill Smelkov1-0/+22
Also as suggested by Junio, in order to try to catch other MIME problems, test cases from the "8. Examples" section of RFC2047 are added to t5100 testsuite as well. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
2009-01-28mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'Libravatar Kirill Smelkov1-1/+1
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
2009-01-10mailinfo: correctly handle multiline 'Subject:' headerLibravatar Kirill Smelkov1-1/+1
When native language (RU) is in use, subject header usually contains several parts, e.g. Subject: [Navy-patches] [PATCH] =?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?= =?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?= =?utf-8?b?0YHQsdC+0YDQutC4?= This exposes several bugs in builtin-mailinfo.c: 1. decode_b_segment: do not append explicit NUL -- explicit NUL was preventing correct header construction on parts concatenation via strbuf_addbuf in decode_header_bq. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па Then 2. Do not emit '\n' between "encoded-word" where RFC2046 says that linear white space between them are ignored when displaying. Fixes: -Subject: Изменён список пакетов необходимых для сборки +Subject: Изменён список па кетов необходимых для сборки Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-20Merge branch 'jc/test-deeper'Libravatar Junio C Hamano1-11/+12
* jc/test-deeper: tests: use $TEST_DIRECTORY to refer to the t/ directory
2008-08-19mailinfo: avoid violating strbuf assertionLibravatar Jeff King1-0/+11
In handle_from, we calculate the end boundary of a section to remove from a strbuf using strcspn like this: el = strcspn(buf, set_of_end_boundaries); strbuf_remove(&sb, start, el + 1); This works fine if "el" is the offset of the boundary character, meaning we remove up to and including that character. But if the end boundary didn't match (that is, we hit the end of the string as the boundary instead) then we want just "el". Asking for "el+1" caught an out-of-bounds assertion in the strbuf library. This manifested itself when we got a 'From' header that had just an email address with nothing else in it (the end of the string was the end of the address, rather than, e.g., a trailing '>' character), causing git-mailinfo to barf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-17tests: use $TEST_DIRECTORY to refer to the t/ directoryLibravatar Junio C Hamano1-11/+12
Many test scripts assumed that they will start in a 'trash' subdirectory that is a single level down from the t/ directory, and referred to their test vector files by asking for files like "../t9999/expect". This will break if we move the 'trash' subdirectory elsewhere. To solve this, we earlier introduced "$TEST_DIRECTORY" so that they can refer to t/ directory reliably. This finally makes all the tests use it to refer to the outside environment. With this patch, and a one-liner not included here (because it would contradict with what Dscho really wants to do): | diff --git a/t/test-lib.sh b/t/test-lib.sh | index 70ea7e0..60e69e4 100644 | --- a/t/test-lib.sh | +++ b/t/test-lib.sh | @@ -485,7 +485,7 @@ fi | . ../GIT-BUILD-OPTIONS | | # Test repository | -test="trash directory" | +test="trash directory/another level/yet another" | rm -fr "$test" || { | trap - exit | echo >&5 "FATAL: Cannot prepare test area" all the tests still pass, but we would want extra sets of eyeballs on this type of change to really make sure. [jc: with help from Stephan Beyer on http-push tests I do not run myself; credits for locating silly quoting errors go to Olivier Marin.] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-09mailinfo: fix MIME multi-part message boundary handlingLibravatar Junio C Hamano1-1/+1
After finding a MIME multi-part message boundary line, the handle_body() function is supposed to first flush any accumulated contents from the previous part to the output stream. However, the code mistakenly output the boundary line it found. The old code that used one global, fixed-length buffer line[] used an alternate static buffer newline[] for keeping track of this accumulated contents and flushed newline[] upon seeing the boundary; when 3b6121f (git-mailinfo: use strbuf's instead of fixed buffers, 2008-07-13) converted a fixed-length buffer in this program to use strbuf,these two buffers were converted to "line" and "prev" (the latter of which now has a much more sensible name) strbufs, but the code mistakenly flushed "line" (which contains the boundary we have just found), instead of "prev". This resulted in the first boundary to be output in front of the first line of the message. The rewritten implementation of handle_boundary() lost the terminating newline; this would then result in the second line of the message to be stuck with the first line. The is_multipart_boundary() was designed to catch both the internal boundary and the terminating one (the one with trailing "--"); this also was broken with the rewrite, and the code in the handle_boundary() to handle the terminating boundary was never triggered. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13git-mailinfo: Fix getting the subject from the in-body [PATCH] lineLibravatar Lukas Sandström1-1/+1
"Subject: " isn't in the static array "header", and thus memcmp("Subject:", header[i], 7) will never match. Even if it did so, hdr_data[] may not have been allocated if there weren't a "Subject: " in-body when we process "[PATCH]" in the affected codepath. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-27t5100: Avoid filename "nul"Libravatar Junio C Hamano1-2/+2
There are broken filesystems that cannot have a file whose name is "nul" anywhere on it. Rename the test file to make ourselves more portable. Noticed by Mark Levedahl. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepathsLibravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25mailsplit and mailinfo: gracefully handle NUL charactersLibravatar Johannes Schindelin1-0/+9
The function fgets() has a big problem with NUL characters: it reads them, but nobody will know if the NUL comes from the file stream, or was appended at the end of the line. So implement a custom read_line_with_nul() function. Noticed by Tommy Thorn. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15mailinfo: feed only one line to handle_filter() for QP inputLibravatar Jay Soffian1-1/+1
The function is intended to be fed one logical line at a time to inspect, but a QP encoded raw input line can have more than one lines, just like BASE64 encoded one. Quoting LF as =0A may be unusual but RFC2045 allows it. The issue was noticed and fixed by Jay Soffian. JC added a test to protect the fix from regressing later. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-3/+3
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-03-12Add a couple more test cases to the suite.Libravatar Don Zickus1-1/+1
They handle cases where there is no attached patch. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27mailinfo: do not get confused with logical lines that are too long.Libravatar Linus Torvalds1-1/+1
It basically considers all the continuation lines to be lines of their own, and if the total line is bigger than what we can fit in it, we just truncate the result rather than stop in the middle and then get confused when we try to parse the "next" line (which is just the remainder of the first line). [jc: added test, and tightened boundary a bit per list discussion.] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17t5100: mailinfo and mailsplit tests.Libravatar Junio C Hamano1-0/+28
Currently the test passes with 1.3.3 but not with the tip of "master". This is to verify the fixes from Eric W Biedermann. Signed-off-by: Junio C Hamano <junkio@cox.net>