On 02/15/2010 12:10 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/12/2010 05:43 PM, John Dennis wrote:
1) Continue to send patches the way we have making sure Thunderbird is
configured to base64 encode them. Accept the fact that when displayed in
a mail reader any UTF-8 will be garbled and you have to manually force
Thunderbird to render the patch in UTF-8. The contents of the patch
remains uncorrupted, it's just a display issue in the mail reader.
2) Configure git-send-email to add the correct SMTP headers and use
git-send-email. This is probably preferred because it's actually correct
from an RFC standpoint.
Option 2 is actually pretty easy to use. My ~/.gitconfig is set up like
this:
[sendemail]
smtpserver = smtp.corp.redhat.com
to = [email protected]
from = John Dennis<[email protected]>
confirm = never
[format]
headers = "Content-Type: text/plain;
charset=\"utf-8\"\nContent-Transfer-Encoding: 8bit\n"
Those defaults in my .gitconfig means I never have to add any command
line args to either git-format-patch or git-send-email, it's as easy as:
% git format-patch -1
% git send-email 0001-some-patch-file
The downside of using git-send-email is whoever is applying the patch
will have to save the entire email to a file instead of an attachment,
which might be slightly more awkward. But as you can see from above it's
very hard, and in most cases impossible, to get a patch sent as an
attachment to have the correct charset specified. This is a pretty
serious shortcoming and calls into question the use of attachments in
the first place.
The problem with option 2 is that you can only send a single patch as a
single email. This makes it difficult to invest a group of patches with
a sense that they are meant to sequentially effect a specific result. I
for one very often submit two or more patches as attachments to the same
email.
From the summary of the git-send-email man page:
"git-send-email - Send a collection of patches as emails"
It sends a sequence of patches as a sequence of emails with an optional
summary email sent first. It sets up threading such that the emails
appear as a group and in order. This is how the kernel team works (or so
I'm lead to believe).
We can also continue to do things as we have, I'm O.K. with that. But we
do need to educate people as to what is actually going on, how we're
violating the RFC's, and how to interpret and adjust for violating those
RFC's, so they can have some trust in what they're seeing on their screen.
It's important for people to know and understand in it's default
configuration Thunderbird (and probably many other mail readers) will
silently display the patch incorrectly. Silently showing the wrong data
but writing different data to a file when the attachment is saved is
IMHO a problem we should not just paper over or wave our hands at. We
should actively understand what is going on and pro-actively modify our
configurations to adjust for our group approved practices.
Furthermore, sometimes it's useful to provide more information about a
patch than you put in the commit message.
I think 'git send-email' is unsuitable for our purposes, and I strongly
recommend the use of base64 encoding.
We can continue to use base64 encoded attachments. We should adjust our
mail readers and other tools to default to UTF-8. We should be aware
that doing so may adversely affect other email we display. We should be
aware base64 encoding our attachments is a hack work-around for our
groups decision to not adhere to RFC's (sometimes that's justified).
Also, for the record, Thunderbird can be configured to use UTF-8 for
incoming and outgoing mail by default. In Thunderbird preferences, go
to Display->Formatting->Fonts& Encodings.
Yes, that helps and we should do that. But at the time someone modifies
their configuration I hope it comes with an awareness of what they are
doing, why they are doing it, and what the adverse consequences might be.
--
John Dennis <[email protected]>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
