René Scharfe <l.s.r@xxxxxx> writes: > That's a good idea from a usability point of view. However, mailinfo() > parses patches line by line. It doesn't know the total number of lines > until it's done. (It would if the Lines header from RFC 1036 was > mandatory for emails; RFC 2076 says it's "not standardized for use in > e-mail".) It cannot easily go back at that point. > > Reading the whole message into a buffer or a temporary file would be an > option, but that would give up the nice property that patches are > streamed. True, but we could do a two-pass approach, perhaps? That is * The first pass does exactly the same as what today's code does, PLUS it prepares for the case where we thought the log message ended because we saw "diff -" or "Index: " before seeing "---", by scanning for the first "---"while running handle_patch(). If there is no such "oops, a 'diff -' in the log message fooled us" event, we complete with what today's code does. * But if we detect such a case during the first pass, we run ourselves again with the same input and arguments, PLUS an extra, new option, which tells us that "we know '---' exists in the input and it *is* the patchbreak. This of course can be done only when the standard input is seekable, but builtin/am.c does store the mail in a file, so...
