Without the "-k" option, mailinfo will convert a folded
subject header like:
Subject: this is a
subject that doesn't
fit on one line
into a single line. With "-k", however, we assumed that
these newlines were significant and represented something
that the sending side would want us to preserve.
For messages created by format-patch, this assumption was
broken by a1f6baa (format-patch: wrap long header lines,
2011-02-23). For messages sent by arbitrary MUAs, this was
probably never a good assumption to make, as they may have
been folding subjects in accordance with rfc822's line
length recommendations all along.
This patch now joins folded lines with a single whitespace
character. This treats header folding purely as a syntactic
feature of the transport mechanism, not as something that
format-patch is trying to tell us about the original
subject.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
The astute reader will notice that even with this patch, there is still
a regression when using new versions of format-patch (with a1f6baa) with
an older version of "git am". But you only see it when using "am -k", so
interoperability is probably not a huge deal:
1. Before this patch, "am -k" was arguably broken anyway for applying
random patches via email, since MUAs may have been doing arbitrary
header folding. So we can probably discount people running "am -k"
on random input as insane.
2. People doing "git format-patch -k | git am -k" will presumably use
the same version for both, and are OK.
3. People doing "git format-patch -k >file", followed by upgrading
git, and t hen "git am file" are still OK, since the newer version
of "am" handles the output of both old and new format-patch.
4. The problematic case is "git format-patch -k >file" with v1.7.5 or
newer, then _downgrading_ git, then using "git am -k" to apply. Or
more likely, using a newer version to create an mbox, shipping the
mbox to another machine, and then using an older "git am" to apply.
So I don't see it as all that likely a problem in practice. If we do
care, we can't fix it with a simple patch. We would have to revert the
header-folding from format-patch, fix am, wait N time units until all of
the old "am" no longer exists, and then re-apply.
builtin/mailinfo.c | 2 +-
t/t4152-am-subjects.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 71e6262..bfb32b7 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -400,7 +400,7 @@ static int read_one_header_line(struct strbuf *line, FILE *in)
break;
if (strbuf_getline(&continuation, in, '\n'))
break;
- continuation.buf[0] = '\n';
+ continuation.buf[0] = ' ';
strbuf_rtrim(&continuation);
strbuf_addbuf(line, &continuation);
}
diff --git a/t/t4152-am-subjects.sh b/t/t4152-am-subjects.sh
index 7222c06..37e5c03 100755
--- a/t/t4152-am-subjects.sh
+++ b/t/t4152-am-subjects.sh
@@ -58,7 +58,7 @@ test_expect_success 'long subject preserved (format-patch | am)' '
test_expect_success 'long subject preserved (format-patch -k | am)' '
check_subject long-k
'
-test_expect_failure 'long subject preserved (format-patch -k | am -k)' '
+test_expect_success 'long subject preserved (format-patch -k | am -k)' '
check_subject long-k -k
'
--
1.7.4.5.26.g0c6a2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html