1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 13:57:54 +01:00
Commit graph

13 commits

Author SHA1 Message Date
Andreas Ericsson
650d30d8a1 mailinfo: Remove only one set of square brackets
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>
2009-07-08 11:22:51 -07:00
Kirill Smelkov
08e6710f76 mailinfo: cleanup extra spaces for complex 'From:'
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>
2009-02-01 12:11:15 -08:00
Kirill Smelkov
806d5e9044 mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
2009-01-28 15:12:24 -08:00
Kirill Smelkov
ddfb3696b9 mailinfo: 'From:' header should be unfold as well
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>
2009-01-12 15:22:11 -08:00
Kirill Smelkov
353aaf2fa1 mailinfo: correctly handle multiline 'Subject:' header
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>
2009-01-10 17:54:30 -08:00
Don Zickus
289796dd29 mailinfo: re-fix MIME multipart boundary parsing
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>
2008-08-18 22:05:02 -07:00
Junio C Hamano
a9fd1383a7 mailinfo: fix MIME multi-part message boundary handling
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-08-09 01:26:35 -07:00
Lukas Sandström
e9fe804a82 git-mailinfo: Fix getting the subject from the in-body [PATCH] line
"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-07-13 17:21:15 -07:00
Jay Soffian
87f1b8849b mailinfo: feed only one line to handle_filter() for QP input
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>
2008-02-15 22:16:34 -08:00
Simon Sasburg
f88a545a94 Make mailsplit and mailinfo strip whitespace from the start of the input
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 01:58:40 -07:00
Don Zickus
ae1a743735 Add a couple more test cases to the suite.
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-03-12 23:33:41 -07:00
Linus Torvalds
34fc5cefa7 mailinfo: do not get confused with logical lines that are too long.
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>
2007-02-27 01:02:32 -08:00
Junio C Hamano
4839c0b5fa t5100: mailinfo and mailsplit tests.
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>
2006-06-17 16:26:20 -07:00