Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes:
>> OPTIONS
>> -------
>> -<mbox>|<Maildir>...::
>> - The list of mailbox files to read patches from. If you do not
>> +<mbox>|<Maildir>...|<email>...::
>> + The list of mailbox files or email to read patches from. If you do not
>> supply this argument, the command reads from the standard input.
>> If you supply directories, they will be treated as Maildirs.
>>
>
> I wasn't following the discussion closely, and at first I didn't understand this change to the documentation, because it doesn't say how <mbox> and <email> are different. I'm afraid many readers of the documentation don't understand it either.
I could tell _you_ that I prefer to see people go back to the list archive
instead of saying "I wasn't following", but I cannot say that to readers
of the documentation after this patch is applied. After re-reading the
above, you are right---it is unclear.
> Why does this description have ... in it? If I'm reading it correctly, the code in check_patch_format function checks only the first file.
Good eyes.
This actually is an issue with the Guiseppe's multi-format support patch
in that we assume that the command line input are of uniform type, check
only $1 and assume $2 and subsequent are suitable to be fed to the same
splitter.
I do not think it is necessary to allow mixed input. We certainly could,
but why bother? It is not a sensible nor common thing to do.
Also the documentation said we take only one mbox or multiple Maildirs,
but in reality we can take multiple mboxes just fine, so <mbox> should
have had "..." at the end (we could lose the ellipses from all of them for
brevity). Oh, and it should list the other formats Giuseppe added.
<mbox>|<maildir>|<email>::
One or more of the same type of mail source to read e-mails
from. A directory is taken as a mailbox in the maildir
format. A file is taken as UNIX mbox, StGit patch series
file, or a single piece of e-mail in RFC2822 format.
--
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