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? -- 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