From: Junio C Hamano <gitster@pobox.com>
To: Tomas Cohen Arazi <tomascohen@gmail.com>
Cc: git@vger.kernel.org
Subject: Re*: Content-Type handling
Date: Mon, 17 Sep 2012 10:18:19 -0700 [thread overview]
Message-ID: <7vy5k8va90.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CABZfb=UhKRREMG_XNJHDJHwbwroi5TKWwgQH-Ge1BDJETizG2Q@mail.gmail.com> (Tomas Cohen Arazi's message of "Mon, 17 Sep 2012 13:34:13 -0300")
Tomas Cohen Arazi <tomascohen@gmail.com> writes:
> Hi, I'm not sure it is a bug, but we used:
>
> git config --global format.headers "Content-Type: text/plain; charset=\"utf-8\""
>
> and recently (perhaps an Ubuntu default setup issue) the content-type
> is being automatically set, the result is that patches contain this:
>
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Content-Type: text/plain; charset="utf-8"
>
> This might not be the problem, but when I apply the patch I get this:
>
> fatal: cannot convert from UTF-8utf-8 to UTF-8
>
> which looks like a bug. Not sure it hasn't been reported before, but I
> think it should take one of the content-type specifications and not
> append both. I couldn't find a place to looks for previous bug reports
> to check, so forgive me if this is not the right place to report it.
What I think is happening is:
* ancient "git format-patch" did not add appropriate content-type
headers, and that bug was fixed in more recent versions.
* while waiting for the bug to get fixed, the user worked around by
having her own format.headers to work it around.
* the user upgraded to a newer version of git without the bug.
* Git trusts that the user knows better than git itself, and it
adds format.headers to whatever it needs to have in the message.
As a message with more than one content-type: is invalid, the
handcrafted format.headers used to be used as a workaround should
be removed, but it hasn't been.
* Then the receiving end (mailinfo) gets confused by the invalid
input.
At least, a patch line this may alleviate the symptom. It seems
that we assumed we won't see multiple charset="..." so the parser,
starting from an empty charset, simply appended whatever it found
in the message, instead of overwriting the old value it had. The
other user of the function this patch touches always makes sure the
"attr" strbuf is empty before calling the function, and wouldn't
have been confused by multiple occurrences of the same header, and
this patch should not affect it, either.
builtin/mailinfo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git i/builtin/mailinfo.c w/builtin/mailinfo.c
index b691b77..2b3f4d9 100644
--- i/builtin/mailinfo.c
+++ w/builtin/mailinfo.c
@@ -160,10 +160,9 @@ static int slurp_attr(const char *line, const char *name, struct strbuf *attr)
const char *ends, *ap = strcasestr(line, name);
size_t sz;
- if (!ap) {
- strbuf_setlen(attr, 0);
+ strbuf_setlen(attr, 0);
+ if (!ap)
return 0;
- }
ap += strlen(name);
if (*ap == '"') {
ap++;
next prev parent reply other threads:[~2012-09-17 17:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 16:34 Content-Type handling Tomas Cohen Arazi
2012-09-17 17:18 ` Junio C Hamano [this message]
2012-09-17 22:28 ` [PATCH] mailinfo: do not concatenate charset= attribute values from mime headers Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vy5k8va90.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=tomascohen@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).