aboutsummaryrefslogtreecommitdiff
path: root/t/t5100
Commit message (Collapse)AuthorAge
* Merge branch 'kd/mailinfo-quoted-string'Junio C Hamano2016-10-03
|\ | | | | | | | | | | | | | | | | | | 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
| * mailinfo: unescape quoted-pair in header fieldsKevin Daudt2016-09-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | mailinfo: handle in-body header continuationsJonathan Tan2016-09-21
|/ | | | | | | | | | | | | | | | | | | | | | | | 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>
* mailsplit: support unescaping mboxrd messagesEric Wong2016-06-06
| | | | | | | | 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>
* git-mailinfo: add --message-idPaolo Bonzini2014-11-25
| | | | | | | | | 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>
* mailinfo: make ">From" in-body header check more robustJeff King2014-09-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'jc/maint-mailinfo-mime-attr'Junio C Hamano2012-09-25
|\ | | | | | | | | | | | | | | When "git am" is fed an input that has multiple "Content-type: ..." header, it did not grok charset= attribute correctly. * jc/maint-mailinfo-mime-attr: mailinfo: do not concatenate charset= attribute values from mime headers
| * mailinfo: do not concatenate charset= attribute values from mime headersJunio C Hamano2012-09-17
| | | | | | | | | | | | | | | | | | | | | | | | "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>
* | diff --stat: use less columns for change countsZbigniew Jędrzejewski-Szmek2012-04-30
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | Number of columns required for change counts is now computed based on the maximum number of changed lines instead of being fixed. This means that usually a few more columns will be available for the filenames and the graph. The graph width logic is also modified to include enough space for "Bin XXX -> YYY bytes". If changes to binary files are mixed with changes to text files, change counts are padded to take at least three columns. And the other way around, if change counts require more than three columns, then "Bin"s are padded to align with the change count. This way, the +- part starts in the same column as "XXX -> YYY" part for binary files. This makes the graph easier to parse visually thanks to the empty column. This mimics the layout of diff --stat before this change. Tests and the tutorial are updated to reflect the new --stat output. This means either the removal of extra padding and/or the addition of up to three extra characters to truncated filenames. One test is added to check the graph alignment when a binary file change and text file change of more than 999 lines are committed together. Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: do not strip leading spaces even for a header lineJunio C Hamano2010-02-19
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ls/maint-mailinfo-no-inbody'Junio C Hamano2009-11-22
|\ | | | | | | | | * ls/maint-mailinfo-no-inbody: git am/mailinfo: Don't look at in-body headers when rebasing
| * git am/mailinfo: Don't look at in-body headers when rebasingLukas Sandström2009-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Mark files in t/t5100 as UTF-8Johannes Sixt2009-10-21
| | | | | | | | | | | | | | | | This enables gitk to show the patch text with correct glyphs if the locale is not UTF-8. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Remove a left-over file from t/t5100Johannes Sixt2009-10-21
|/ | | | | | | | This mbox file must have been added by accident in e9fe804 (git-mailinfo: Fix getting the subject from the in-body [PATCH] line, 2008-07-14). Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* am/mailinfo: Disable scissors processing by defaultJunio C Hamano2009-08-26
| | | | | | You can enable it by giving --scissors to "git am". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach mailinfo to ignore everything before -- >8 -- markJunio C Hamano2009-08-26
| | | | | | | | | 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>
* Revert "mailinfo: Remove only one set of square brackets"v1.6.4-rc1Junio C Hamano2009-07-15
| | | | | | | | | | | | This reverts commit 650d30d8a120c8982309ccb9ef40432b4ea2eb74. Some mailing lists are configured add prefix "[listname] " to all their messages, and also people hand-edit subject lines, be it an output from format-patch or a patch generated by some other means. We cannot stop people from mucking with the subject line, and with the change, there always will be need for hand editing the subject when that happens. People have depended on the leading [bracketed string] removal.
* Merge branch 'ae/maint-mailinfo-rm-only-one-patch-marker'Junio C Hamano2009-07-10
|\ | | | | | | | | * ae/maint-mailinfo-rm-only-one-patch-marker: mailinfo: Remove only one set of square brackets
| * mailinfo: Remove only one set of square bracketsAndreas Ericsson2009-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-format-patch prepends patches with a [PATCH x/n] prefix, but mailinfo used to remove any number of square-bracket pairs and the content between them. This prevents one from using a commit subject like this: [ and ] must be allowed as input Removing the square bracket pair from this rather clumsily constructed subject line loses important information, so we must take care not to. This patch causes the subject stripping to stop after it has encountered one pair of square brackets. One possible downside of this patch is that the patch-handling programs will now fail at removing author-added square-brackets to be removed, such as [RFC][PATCH x/n] However, since format-patch only adds one set of square brackets, this behaviour is quite easily undesrstood and defended while the previous behaviour is not. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t5100: use ancient encoding syntax for backwards compatibilityBrandon Casey2009-05-18
|/ | | | | | | | | | | | | | | | | Some ancient platforms do not have an extensive list of alternate names for character encodings. For example, Solaris 7 does not know that ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use the older names. The following conversions were performed: ISO-8859-1 --> ISO8859-1 ISO-8859-2 --> ISO8859-2 ISO-8859-8 --> ISO8859-8 iso-2022-jp --> ISO-2022-JP Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: cleanup extra spaces for complex 'From:'Kirill Smelkov2009-02-01
| | | | | | | | | | | | | | | | | currently for cases like From: A U Thor <a.u.thor@example.com> (Comment) mailinfo extracts the following 'Author:' field: Author: A U Thor (Comment) ^^ which has two extra spaces left in there after removed email part. I think this is wrong so here is a fix. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: tests for RFC2047 examplesKirill Smelkov2009-01-28
| | | | | | | | 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>
* mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'Kirill Smelkov2009-01-28
| | | | Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
* mailinfo: 'From:' header should be unfold as wellKirill Smelkov2009-01-12
| | | | | | | | | | At present we do headers unfolding (see RFC822 3.1.1. LONG HEADER FIELDS) for all fields except 'From' (always) and 'Subject' (when keep_subject is set) Not unfolding 'From' is a bug -- see above-mentioned RFC link. Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: correctly handle multiline 'Subject:' headerKirill Smelkov2009-01-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mailinfo: avoid violating strbuf assertionJeff King2008-08-19
| | | | | | | | | | | | | | | | | | | | | | | 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>
* mailinfo: re-fix MIME multipart boundary parsingDon Zickus2008-08-18
| | | | | | | | | | | | | | | | | | Recent changes to is_multipart_boundary() caused git-mailinfo to segfault. The reason was after handling the end of the boundary the code tried to look for another boundary. Because the boundary list was empty, dereferencing the pointer to the top of the boundary caused the program to go boom. The fix is to check to see if the list is empty and if so go on its merry way instead of looking for another boundary. I also fixed a couple of increments and decrements that didn't look correct relating to content_top. The boundary test case was updated to catch future problems like this again. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: fix MIME multi-part message boundary handlingJunio C Hamano2008-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* git-mailinfo: Fix getting the subject from the in-body [PATCH] lineLukas Sandström2008-07-13
| | | | | | | | | | | "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>
* t5100: Avoid filename "nul"Junio C Hamano2008-05-27
| | | | | | | | | 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>
* mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepathsJunio C Hamano2008-05-25
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailsplit and mailinfo: gracefully handle NUL charactersJohannes Schindelin2008-05-25
| | | | | | | | | | | | | 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>
* mailinfo: feed only one line to handle_filter() for QP inputJay Soffian2008-02-15
| | | | | | | | | | | | | | 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>
* Make mailsplit and mailinfo strip whitespace from the start of the inputSimon Sasburg2007-11-02
| | | | | Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-mailinfo fixes for patch mungingDon Zickus2007-03-31
| | | | | | | | | | | | | Don't translate the patch to UTF-8, instead preserve the data as is. This also reverts a test case that was included in the original patch series. Also allow overwriting the authorship and title information we gather from RFC2822 mail headers with additional in-body headers, which was pointed out by Linus. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Add a couple more test cases to the suite.Don Zickus2007-03-12
| | | | | | | 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>
* builtin-mailinfo.c infrastrcture changesDon Zickus2007-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am working on a project that required parsing through regular mboxes that didn't necessarily have patches embedded in them. I started by creating my own modified copy of git-am and working from there. Very quickly, I noticed git-mailinfo wasn't able to handle a big chunk of my email. After hacking up numerous solutions and running into more limitations, I decided it was just easier to rewrite a big chunk of it. The following patch has a bunch of fixes and features that I needed in order for me do what I wanted. Note: I'm didn't follow any email rfc papers but I don't think any of the changes I did required much knowledge (besides the boundary stuff). List of major changes/fixes: - can't create empty patch files fix - empty patch files don't fail, this failure will come inside git-am - multipart boundaries are now handled - only output inbody headers if a patch exists otherwise assume those headers are part of the reply and instead output the original headers - decode and filter base64 patches correctly - various other accidental fixes I believe I didn't break any existing functionality or compatibility (other than what I describe above, which is really only the empty patch file). I tested this through various mailing list archives and everything seemed to parse correctly (a couple thousand emails). [jc: squashed in another patch from Don's five patch series to fix the test case, as this patch exposes the bug in the test.] Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* mailinfo: do not get confused with logical lines that are too long.Linus Torvalds2007-02-27
| | | | | | | | | | | | | 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>
* t5100: mailinfo and mailsplit tests.Junio C Hamano2006-06-17
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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-28 02:43:58 +0000