Re: FEATURE REQUEST: git-format-path: Add option to encode patch content

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