Re: [PATCH] format-patch: Properly escape From_ lines when creating an mbox.
On 06/08/2010 08:50 PM, Junio C Hamano wrote:
Show 32 quoted lines
> Carl Worth <cworth@cworth.org> writes:
>
>> Without this patch series, there's no documented way that an external
>> tool can use to reliably construct an mbox that will be correctly handled
>> by "git am". The best one could do is to peek inside the git implementation
>> and notice that it wants unescaped "From " lines, that it will ignore any
>> "From " line that doesn't end with something very much like asctime format,
>> and then somehow ensure that no messages in the mbox have lines that begin
>> with "From " and end with something like asctime format, (which won't be
>> possible in all cases without corrupting the message).
>
> I have this small suspicion that mboxrd may be a suboptimal choice, when
> you consider how robustly we can notice a failure (and to a lessor extent,
> recover from it) when using output from "format-patch --stdout" to
> sneakernet between existing and updated versions of git. Especially
> because your implementation quotes lines that begin with "From "
> unconditionally (even when the tail end of the line would never be a
> valid-looking timestamp). Such an output will confuse existing mailsplit,
> but the worst part of the story is that somebody who is applying a series
> of patches will _not_ notice the breakage. The payload of the second and
> subsequent messages will likely be concatenated as if it were part of the
> first message, ignoring cruft between patches, but the resulting tree
> would likely to be the same as what the sending end intended.
>
> Compared to that, I think a failure to split a message in the middle (iow,
> commit message happened to have a line that begins with "From " and ends
> with a timestamp-looking string) is much easier to notice (because the
> first part of the message that was incorrectly split at such a line will
> not have any patch, so "git am" will stop). IOW, failure to split is
> easier to notice than splitting too eagerly.
>
> Perhaps perfect is an enemy of good?
For production perhaps we should do the MIME-escape thing?
For consumption, it's not so clear...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.