On 06/08/2010 08:50 PM, Junio C Hamano wrote: > Carl Worth <cworth@xxxxxxxxxx> 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. -- 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