Re: [PATCH] Add MIME information to outgoing email

Samuel Tardieu [off-list ref] writes:

Add MIME-Version/Content-Type/Content-Transfer-Encoding headers in
messages generated with git-format-patch. Without it, messages generated
without using --attach or --inline didn't have any content type information.

Isn't that job for send-email (or user's MUA)?  I really do not think we
want to clutter format-patch output any more than necessary.

On 13/03, Junio C Hamano wrote:

| Samuel Tardieu [off-list ref] writes:
| 
| > Add MIME-Version/Content-Type/Content-Transfer-Encoding headers in
| > messages generated with git-format-patch. Without it, messages generated
| > without using --attach or --inline didn't have any content type information.
| 
| Isn't that job for send-email (or user's MUA)?  I really do not think we
| want to clutter format-patch output any more than necessary.

Only format-patch knows what encoding has been used by itself to
generate the message. Doing it at any later stage would have to guess
what the correct charset is.

[Samuel Tardieu [off-list ref]]

On 13/03, Junio C Hamano wrote:

| Samuel Tardieu [off-list ref] writes:
| 
| > Add MIME-Version/Content-Type/Content-Transfer-Encoding headers in
| > messages generated with git-format-patch. Without it, messages generated
| > without using --attach or --inline didn't have any content type information.
| 
| Isn't that job for send-email (or user's MUA)?  I really do not think we
| want to clutter format-patch output any more than necessary.

Only format-patch knows what encoding has been used by itself to
generate the message. Doing it at any later stage would have to guess
what the correct charset is.

When the encoded string is entirely ascii except for one or two characters
(such as occurs in a lot of patches I handle from people with names
not represented in plain ascii) guessing later on seems to run pretty
high risk of guessing wrong.

I've taken to manually adding UTF-8 content-type/transfer-encoding
headers to avoid the routine mangling of my coworkers' names and
would welcome a change to do this automatically.

Considering that UTF-8 is the expected default encoding (right?) for
git metadata, it seems to be the sane thing to indicate if the default
is unchanged.

Brian

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 14/03, Brian Swetland wrote:

| > Only format-patch knows what encoding has been used by itself to
| > generate the message. Doing it at any later stage would have to guess
| > what the correct charset is.
| 
| When the encoded string is entirely ascii except for one or two characters
| (such as occurs in a lot of patches I handle from people with names
| not represented in plain ascii) guessing later on seems to run pretty
| high risk of guessing wrong.
| [...]
| Considering that UTF-8 is the expected default encoding (right?) for
| git metadata, it seems to be the sane thing to indicate if the default
| is unchanged.

Yup.

Junio C Hamano kirjoitti:

Samuel Tardieu [off-list ref] writes:

quoted

Add MIME-Version/Content-Type/Content-Transfer-Encoding headers in
messages generated with git-format-patch. Without it, messages
generated without using --attach or --inline didn't have any
content type information.

Isn't that job for send-email (or user's MUA)?  I really do not think
we want to clutter format-patch output any more than necessary.

By the way, 'git send-email --compose' does not add MIME headers to 
introductory message. All non-Ascii chars will output something 
undefined in receivers' end.

I guess the right way would be to detect user's charset (locale) and add 
appropriate MIME headers. Also, the Subject field should be encoded if 
it contains non-Ascii characters.

On Tue, Mar 25, 2008 at 2:31 PM, Teemu Likonen [off-list ref] wrote:

Junio C Hamano kirjoitti:

 > Samuel Tardieu [off-list ref] writes:
 > > Add MIME-Version/Content-Type/Content-Transfer-Encoding headers in
 > > messages generated with git-format-patch. Without it, messages
 > > generated without using --attach or --inline didn't have any
 > > content type information.
 >
 > Isn't that job for send-email (or user's MUA)?  I really do not think
 > we want to clutter format-patch output any more than necessary.

 By the way, 'git send-email --compose' does not add MIME headers to
 introductory message. All non-Ascii chars will output something
 undefined in receivers' end.

 I guess the right way would be to detect user's charset (locale) and add
 appropriate MIME headers. Also, the Subject field should be encoded if
 it contains non-Ascii characters.

I stuck this in my config and it works-for-me:

[format]
	headers = \
"MIME-Version: 1.0\n\
Content-Type: text/plain; charset=UTF-8\n\
Content-Transfer-Encoding: 8bit\n"

Shrug. (Never tried putting non-ascii in the subject tho.)

j.

On Tue, Mar 25, 2008 at 08:31:16PM +0200, Teemu Likonen wrote:

By the way, 'git send-email --compose' does not add MIME headers to 
introductory message. All non-Ascii chars will output something 
undefined in receivers' end.

I guess the right way would be to detect user's charset (locale) and add 
appropriate MIME headers. Also, the Subject field should be encoded if 
it contains non-Ascii characters.

I just posted some patches to fix this; however, they always encode as
utf-8. I'm not sure what is the best way to find the user's encoding.
AIUI, locale environment variables are not enough, since, e.g., "en_US"
could come in iso8859-1 and utf-8 flavors. Is there a portable way to
figure this out? Should we be pulling it from .git/config? Neither the
commitEncoding nor the logOutputEncoding really makes sense to reuse.

-Peff

On Tue, Mar 25, 2008 at 7:06 PM, Jeff King [off-list ref] wrote:

On Tue, Mar 25, 2008 at 08:31:16PM +0200, Teemu Likonen wrote:

 > By the way, 'git send-email --compose' does not add MIME headers to
 > introductory message. All non-Ascii chars will output something
 > undefined in receivers' end.
 >
 > I guess the right way would be to detect user's charset (locale) and add
 > appropriate MIME headers. Also, the Subject field should be encoded if
 > it contains non-Ascii characters.

 I just posted some patches to fix this; however, they always encode as
 utf-8. I'm not sure what is the best way to find the user's encoding.
 AIUI, locale environment variables are not enough, since, e.g., "en_US"
 could come in iso8859-1 and utf-8 flavors. Is there a portable way to
 figure this out? Should we be pulling it from .git/config?

I think so. There's no reason the message encoding necessarily matches the
locale anyway. There are ways to guess, but I think .git/config is sanest
with UTF-8 as the default.

j.

On Tue, Mar 25, 2008 at 19:06:49 -0400, Jeff King wrote:

On Tue, Mar 25, 2008 at 08:31:16PM +0200, Teemu Likonen wrote:

quoted

By the way, 'git send-email --compose' does not add MIME headers to 
introductory message. All non-Ascii chars will output something 
undefined in receivers' end.

I guess the right way would be to detect user's charset (locale) and add 
appropriate MIME headers. Also, the Subject field should be encoded if 
it contains non-Ascii characters.

I just posted some patches to fix this; however, they always encode as
utf-8. I'm not sure what is the best way to find the user's encoding.
AIUI, locale environment variables are not enough, since, e.g., "en_US"
could come in iso8859-1 and utf-8 flavors. Is there a portable way to
figure this out? Should we be pulling it from .git/config? Neither the
commitEncoding nor the logOutputEncoding really makes sense to reuse.

The portable way is to use the locale environment variables, but you have to
read them via the libc locale interface. You set the LC_CTYPE locale category
via setlocale (which will consult LC_CTYPE, LC_ALL and LANG environment AND
the locale database) and than ask for charset using nl_langinfo(CODESET).
To do the equivalent from the shell, call `locale charmap`. From perl, either
use langinfo in I18N::Langinfo, or just use the ':locale' IO stream option
provided by encoding pragma to read the file in unicode no matter what the
locale encoding was (this is perl 5.8.<something> -- in older one, you'd have
to use I18N::Langinfo anyway).

-- 
						 Jan 'Bulb' Hudec [off-list ref]