Граф коммитов

3 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 4525e8e41a Revert "mailinfo: Remove only one set of square brackets"
This reverts commit 650d30d8a1.

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.
2009-07-15 15:10:06 -07:00
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 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