[PATCH]: Optional explanation for options

[Robey Pointer]

On 19 Sep 2005, at 3:41, Lars Wirzenius wrote:

> ma, 2005-09-19 kello 19:12 +1000, Robert Collins kirjoitti:
>
>> On Mon, 2005-09-19 at 09:59 +0100, Magnus Therning wrote:
>> ..
>>
>>> That'd mean they mess up digital signatures as well, right?
>>>
>>
>> RFC???? signatures are done by having an empty body, two MIME
>> attachments, one of which is the signature and the other the content.
>>
>
> I think you mean RFC2015 (http://www.ietf.org/rfc/rfc2015.txt). More
> links at http://www.imc.org/smime-pgpmime.html if you want.

[lucid & interesting description omitted]

> I'll say something about MTAs, MUAs, and other mail processing
> software and whether they mangle messages.
>
> They do, we have to live with it. There is practically no part of any
> Internet e-mail specification that isn't being violated daily,  
> somewhere
> on the network.

[...]

> It makes sense to keep or the patch format insensitive to the  
> commonest
> manglings: trailing whitespace is eaten, line terminators are  
> converted,
> tabs might get expanded, a ">" is added before a "From" at the  
> beginning
> of a line, and so on. At least to make possible to detect that  
> something
> has been mangled; an embedded checksum (of a normalized version that
> disregards line terminator changes), for example, could easily be  
> used,
> and won't disturb the patch utility, which happily ignores things
> outside the parts it's supposed to apply (an ingenious design  
> decision).

Assuming that users never care about tab-vs-space or trailing  
whitespace in files under revision control, we could "normalize" a  
patch on receipt.  But unless the original commit is mangled *at  
commit time*, we'll still lose, because the SHA1's used for ancestor  
matching will be different. :(  This is what I ran into  
before.  ...And I don't think that assumption is a good one to make.   
Some people do care about tabs: what if I checked in a Makefile?

My friends and I (offlist) tried to think of solutions to this,  
including wacky things like encoding the location of all tabs and  
trailing whitespace in the footer so that the original patch could be  
reconstituted.  None of these solutions seemed reasonable, so I gave  
it up.

I think you're right that the best thing to do is to include a  
verification hash (SHA1 or whatever) so we can detect munged patches  
before trying to apply them... and encourage people to send  
changesets as attachments.

robey