Re: git am should recognize >From

Re: git am should recognize >From

[Jonathan Nieder]

(+cc: some "git am" people. Unfortunately I will probably be hard to
reach for another week or so.)

Russ Allbery wrote:

> I process a lot of git format-patch patches as attachments, but it's
> common for mailers to mangle the leading "From " line by adding a >.
> This causes git am to not recognize the patch

Ignoring a leading ">" sounds sane to me at first glance; thanks. (The
file to patch is git-am.sh, hint hint. ;-))

Re: git am should recognize >From

[Jonathan Nieder]

Russ Allbery wrote:

> I process a lot of git format-patch patches as attachments,

Aside: it seems that many format-patch users are not using it to
generate an mbox with a template message, as originally intended;
instead, they just write a cover letter and attach the generated
patches to it. Are we not advertising the "am --scissors" facility[1]
well enough?

Maybe format-patch could provide another mode to produce patches that
do not include unnecessary headers (in particular, leaving out the
difficult "From " line and using UTF-8 instead of quoted-printable for
the "From: " line).

All that is irrelevant to the "git am" feature suggestion, of course.

Thanks for a reminder,
Jonathan

[1]
 > lorem ipsum etc etc
 ... reply as usual ...
 ...
 How about this patch?
 -- 8< --
 From: Patch Author <au.thor@example.com>
 Subject: foo: do "bar" better

 patch description
 ---
 ... patch ...

Re: git am should recognize >From

[Russ Allbery]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Aside: it seems that many format-patch users are not using it to
> generate an mbox with a template message, as originally intended;

Myself included.  I don't like other things sending mail for me outside of
my normal mail client, since my normal mail client does lots of other
things (like know what From address to use, save copies of outgoing mail,
etc.).

> instead, they just write a cover letter and attach the generated patches
> to it. Are we not advertising the "am --scissors" facility[1] well
> enough?

That seems like a bad substitute for real MIME structure.  My experience
is that patches as actual MIME attachments fare much better and are much
less likely to be mangled when getting to the committer than patches
inlined in the body of a message.  (Yes, this is a 180 degree reversal
from the situation about ten years ago.)

Speaking of git am features, it would also be lovely if git am would
recognize and accept the format produced by git show, since a lot of
beginning Git users tend towards git show output instead of git
format-patch.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Make format-patch produce UTF-8 `From:' header (was Re: git am should recognize >From)

[Štěpán Němec]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Maybe format-patch could provide another mode to produce patches that
> do not include unnecessary headers (in particular, leaving out the
> difficult "From " line and using UTF-8 instead of quoted-printable for
> the "From: " line).

FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
replace it manually with my name & address in UTF-8 every time I send
out a patch. What is the reason format-patch does that (and if there is
a reason not to change the default, could an option to disable it be
provided)?

Štěpán

Re: Make format-patch produce UTF-8 `From:' header

[Russ Allbery]

Štěpán Němec <stepnem@gmail.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Maybe format-patch could provide another mode to produce patches that
>> do not include unnecessary headers (in particular, leaving out the
>> difficult "From " line and using UTF-8 instead of quoted-printable for
>> the "From: " line).

> FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
> replace it manually with my name & address in UTF-8 every time I send
> out a patch. What is the reason format-patch does that (and if there is
> a reason not to change the default, could an option to disable it be
> provided)?

Well, it's required if you're going to actually send the result directly
as a mail message, since the RFC 5322 format requires headers be encoded
using RFC 2047 encoding.  But if you're just attaching the patch to
another mail message, it's pointless.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

use base64 instead of quoted-printable in format-patch headers (was Re: Make format-patch produce UTF-8 `From:' header)

[Štěpán Němec]

Russ Allbery <rra@debian.org> writes:

> Štěpán Němec <stepnem@gmail.com> writes:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> Maybe format-patch could provide another mode to produce patches that
>>> do not include unnecessary headers (in particular, leaving out the
>>> difficult "From " line and using UTF-8 instead of quoted-printable for
>>> the "From: " line).
>
>> FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
>> replace it manually with my name & address in UTF-8 every time I send
>> out a patch. What is the reason format-patch does that (and if there is
>> a reason not to change the default, could an option to disable it be
>> provided)?
>
> Well, it's required if you're going to actually send the result directly
> as a mail message, since the RFC 5322 format requires headers be encoded
> using RFC 2047 encoding.

Right... thanks for pointing that out. So the problem I'm seeing is
actually different -- some software (including Mutt and the mailing
list/archive software used by this list) appears to have problems with
quoted-printable, but not with base64.

To take my name as example: when I send mail from Mutt, it is encoded as
"=?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?=", i.e. base64, and both Mutt and
the vger archive seem to decode it properly, whereas the
quoted-printable version produced by fromat-patch, i.e.
"=?utf-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=" in this case, is left
undecoded by Mutt and mis-decoded in the ML archive as far as I have
seen. I'm not sure about other software (Gnus seems to be able to deal
with both correctly), but perhaps it would make sense to switch to
base64 in format-patch?

Štěpán

Re: use base64 instead of quoted-printable in format-patch headers (was Re: Make format-patch produce UTF-8 `From:' header)

[Ævar Arnfjörð Bjarmason]

On Mon, Sep 20, 2010 at 12:20, Štěpán Němec <stepnem@gmail.com> wrote:
> Russ Allbery <rra@debian.org> writes:
>
>> Štěpán Němec <stepnem@gmail.com> writes:
>>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>>> Maybe format-patch could provide another mode to produce patches that
>>>> do not include unnecessary headers (in particular, leaving out the
>>>> difficult "From " line and using UTF-8 instead of quoted-printable for
>>>> the "From: " line).
>>
>>> FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
>>> replace it manually with my name & address in UTF-8 every time I send
>>> out a patch. What is the reason format-patch does that (and if there is
>>> a reason not to change the default, could an option to disable it be
>>> provided)?
>>
>> Well, it's required if you're going to actually send the result directly
>> as a mail message, since the RFC 5322 format requires headers be encoded
>> using RFC 2047 encoding.
>
> Right... thanks for pointing that out. So the problem I'm seeing is
> actually different -- some software (including Mutt and the mailing
> list/archive software used by this list) appears to have problems with
> quoted-printable, but not with base64.
>
> To take my name as example: when I send mail from Mutt, it is encoded as
> "=?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?=", i.e. base64, and both Mutt and
> the vger archive seem to decode it properly, whereas the
> quoted-printable version produced by fromat-patch, i.e.
> "=?utf-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=" in this case, is left
> undecoded by Mutt and mis-decoded in the ML archive as far as I have
> seen. I'm not sure about other software (Gnus seems to be able to deal
> with both correctly), but perhaps it would make sense to switch to
> base64 in format-patch?

The advantage of quoted-printable is the printable part. It's at least
somewhat human readable, e.g.:

    =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?=

I have some chance of spotting a typo or something in there if I look
at the raw E-Mail (which I often do), but not with base64.

Are we sure we're correctly encoding quoted-printable? E.g. maybe
?UTF-8? instead of ?utf-8? would work? It seems odd that a widely used
client like Mutt would screw up such a widely used encoding.

Re: use base64 instead of quoted-printable in format-patch headers (was Re: Make format-patch produce UTF-8 `From:' header)

[Brandon Casey]

On 09/20/2010 08:46 AM, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Sep 20, 2010 at 12:20, Štěpán Němec <stepnem@gmail.com> wrote:
>> Russ Allbery <rra@debian.org> writes:
>>
>>> Štěpán Němec <stepnem@gmail.com> writes:
>>>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>>
>>>>> Maybe format-patch could provide another mode to produce patches that
>>>>> do not include unnecessary headers (in particular, leaving out the
>>>>> difficult "From " line and using UTF-8 instead of quoted-printable for
>>>>> the "From: " line).
>>>
>>>> FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
>>>> replace it manually with my name & address in UTF-8 every time I send
>>>> out a patch. What is the reason format-patch does that (and if there is
>>>> a reason not to change the default, could an option to disable it be
>>>> provided)?
>>>
>>> Well, it's required if you're going to actually send the result directly
>>> as a mail message, since the RFC 5322 format requires headers be encoded
>>> using RFC 2047 encoding.
>>
>> Right... thanks for pointing that out. So the problem I'm seeing is
>> actually different -- some software (including Mutt and the mailing
>> list/archive software used by this list) appears to have problems with
>> quoted-printable, but not with base64.
>>
>> To take my name as example: when I send mail from Mutt, it is encoded as
>> "=?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?=", i.e. base64, and both Mutt and
>> the vger archive seem to decode it properly, whereas the
>> quoted-printable version produced by fromat-patch, i.e.
>> "=?utf-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?=" in this case, is left
>> undecoded by Mutt and mis-decoded in the ML archive as far as I have
>> seen. I'm not sure about other software (Gnus seems to be able to deal
>> with both correctly), but perhaps it would make sense to switch to
>> base64 in format-patch?
> 
> The advantage of quoted-printable is the printable part. It's at least
> somewhat human readable, e.g.:
> 
>     =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?=
> 
> I have some chance of spotting a typo or something in there if I look
> at the raw E-Mail (which I often do), but not with base64.
> 
> Are we sure we're correctly encoding quoted-printable? E.g. maybe
> ?UTF-8? instead of ?utf-8? would work? It seems odd that a widely used
> client like Mutt would screw up such a widely used encoding.

I don't think we should be producing lower-case utf-8 anymore, since
1.6.4 I think.

I have encountered platforms, like older Solaris or IRIX, that indeed
did not understand utf-8, but did understand UTF-8.  So, it is something
to check out.  Perhaps Mutt or the mailing list archive were running
on such a system?

-Brandon

Re: use base64 instead of quoted-printable in format-patch headers

[Štěpán Němec]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> The advantage of quoted-printable is the printable part. It's at least
> somewhat human readable, e.g.:
>
>     =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?=
>
> I have some chance of spotting a typo or something in there if I look
> at the raw E-Mail (which I often do), but not with base64.

...apart from all the UTF-8 bytes and/or unless the name does not
contain any ASCII characters at all; anyway, I don't consider this
argument very compelling, but see below.

> Are we sure we're correctly encoding quoted-printable? E.g. maybe
> ?UTF-8? instead of ?utf-8? would work?

As per RFC 2047, both the charset (`utf-8') and encoding (`q') are
case-insensitive, so this shouldn't matter.

> It seems odd that a widely used client like Mutt would screw up such a
> widely used encoding.

Actually, upon some tests and repeated closer examination, I obviously
mis-diagnosed the problem once again (I really apologize for all the
noise). It appears that when I send an e-mail from Mutt using the file
produced by `git format-patch' as a template (i.e. `mutt -H some.patch'
-> edit -> send), Mutt for some reason re-encodes the already encoded
`From:' header, resulting in

From: =?utf-8?B?PT9VVEYtOD9xPz1DNT1BMHQ9QzQ9OUJwPUMzPUExbj0yME49QzQ9OUJt?=
        =?utf-8?Q?ec=3F=3D?= <stepnem@gmail.com>

...which doesn't make much sense to me (or Mutt or Gnus).

So this probably really belongs in some Mutt help forum... I'm sorry.
(If someone knows how to work around the problem, please let me know).

Štěpán

Re: Make format-patch produce UTF-8 `From:' header (was Re: git am should recognize >From)

[Erik Faye-Lund]

On Sun, Sep 19, 2010 at 8:38 PM, Štěpán Němec <stepnem@gmail.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Maybe format-patch could provide another mode to produce patches that
>> do not include unnecessary headers (in particular, leaving out the
>> difficult "From " line and using UTF-8 instead of quoted-printable for
>> the "From: " line).
>
> FWIW, the quoted-printable `From:' encoding has always annoyed me -- I
> replace it manually with my name & address in UTF-8 every time I send
> out a patch. What is the reason format-patch does that (and if there is
> a reason not to change the default, could an option to disable it be
> provided)?
>

I believe the reason is that RFC 5322 doesn't allow header-fields to
be encoded in other ways that by QP, but I could be wrong.

QP being used even when the "From:"-line is inlined in the message
body seems to be an artefact of the way it's done, and should be
possible to avoid.