threads / discuss / 25151
Subject: 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. ;-))
Jonathan NiederRuss 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 ...
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/>
Štěpán NěmecMake format-patch produce UTF-8 `From:' header (was Re: git am should recognize >From)
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
Š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/>
Štěpán Němecuse base64 instead of quoted-printable in format-patch headers (was Re: Make format-patch produce UTF-8 `From:' header)
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
Ævar Arnfjörð BjarmasonRe: use base64 instead of quoted-printable in format-patch headers (was Re: Make format-patch produce UTF-8 `From:' header)
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)
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
Štěpán NěmecRe: use base64 instead of quoted-printable in format-patch headers
Æ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
Erik Faye-LundRe: Make format-patch produce UTF-8 `From:' header (was Re: git am should recognize >From)
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.