On Fri, 27 Apr 2007 12:49:02 -0700, Junio C Hamano wrote: > Keeping patches reviewable in recipient's MUA is important. Absolutely. > In the community git originates from, even --inline attachments > are frowned upon, let alone --attach multiparts (yes, I am > talking about the kernel list and this list). Nobody who sends > patches over e-mail in communities that have a tradition against > unreadable patches would be using --inline nor --attach anyway, > so making --attach to do base64 would not hurt there. I know I'm not within the kernel or git party line by saying this, but I don't have a problem with (non base64) mime-attached patches. My MUA displays them fine and quotes them when I reply so I can easily review them. I have even wished that git-am would accept a message with multiple attachments and apply each in series. But, no, I'm not about to write that myself either. Instead we've gotten by with using the output of "git format-patch --stdout from..to > feature.patchset" and attaching that. But even then, I'd like something like git-am that knew how to process an email message like that, (that is, not trying to use the subject and from lines for commit information). As is, I just have to arrange for the attachment to get piped to git-am instead of the entire message. If nothing else, there's a datapoint from a separate community that also has a tradition against unreadable patches. My MUA doesn't have support (that I know of) for piping a sequence of messages to a command. Do your MUAs? If not, how do people generally handle long sequences of [n/N] patch emails? -Carl
Attachment:
pgpZwRPz7uMEX.pgp
Description: PGP signature