On Fri, Feb 15, 2008 at 09:10:19AM -0800, Junio C Hamano wrote: > I really do not like this. > > format=flowed instructs the receivers MUA that it is Ok to > reflow the text when the message is presented to the user. That > is exactly what we do _NOT_ want to happen to patches. Your > implementation may cleanly salvage what the sender intended to > send, but salvaging when applying the patch is too late. > > You review the patch, decide to apply or reject, and then > finally apply. Unmangling of corrupt contents should be done > before you review, not before you apply. I have to agree that this is a bad idea - for the reasons stated, and one additional: There are MUA's which send 'format=fixed' email marked as 'format=flowed'. At which point the receiving MUA performing the deflowing _will_ get a corrupt patch. I saw this recently wrt to internal company code reviews. We have a variety of different MUAs in use on a variety of different OSs. Some 'properly' implement format=flowed, some do not. Some always send format=flowed for text, some can have it disabled to send format=fixed. Despite what the RFCs say, some of them also QP or base64 encode such flowed pieces of text. It is a nightmare. However it seems thay all use fixed format for attachments, unfortunately some them always tag those as application/octet-stream, so one cannot automatically process them (in the absense of other clues). I am able to work around some of these issues by configuing mutt to do some guesses when it sees application/x-patch, or application/octet-stream and a file with say as '.diff' extension. But ultimately for some of these one is forced to contact the original author and get access to the actual patch file on the filesystem. While this can be done for a 'small' community, it is not something that would work in the wider world. So - format=flowed is simply unsuitable for fixed format text and should not be used. [Actually it rather turns out format=flowed is a bad idea all together, you should see what it does to log files...] DF - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
