| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
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>
|
|
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>
|
Junio C Hamano
Andreas Ericsson
Kirill Smelkov