prefix defaults to
	"PATCH", you'll get "RFC PATCH" by default.
+
RFC means "Request For Comments"; use this when sending
an experimental patch for discussion rather than application.
"--rfc=WIP" may also be a useful way to indicate that a patch
is not complete yet ("WIP" stands for "Work In Progress").
+
If the convention of the receiving community for a particular extra
string is to have it _after_ the subject prefix, the string _<rfc>_
can be prefixed with a dash ("`-`") to signal that the rest of
the _<rfc>_ string should be appended to the subject prefix instead,
e.g., `--rfc='-(WIP)'` results in "PATCH (WIP)".

-v <n>::
--reroll-count=<n>::
	Mark the series as the <n>-th iteration of the topic. The
	output filenames have `v<n>` prepended to them, and the
	subject prefix ("PATCH" by default, but configurable via the
	`--subject-prefix` option) has ` v<n>` appended to it.  E.g.
	`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
	file that has "Subject: [PATCH v4 1/20] Add makefile" in it.
	`<n>` does not have to be an integer (e.g. "--reroll-count=4.4",
	or "--reroll-count=4rev2" are allowed), but the downside of
	using such a reroll-count is that the range-diff/interdiff
	with the previous version does not state exactly which
	version the new iteration is compared against.

--to=<email>::
	Add a `To:` header to the email headers. This is in addition
	to any configured headers, and may be used multiple times.
	The negated form `--no-to` discards all `To:` headers added so
	far (from config or command line).

--cc=<email>::
	Add a `Cc:` header to the email headers. This is in addition
	to any configured headers, and may be used multiple times.
	The negated form `--no-cc` discards all `Cc:` headers added so
	far (from config or command line).

--from::
--from=<ident>::
	Use `ident` in the `From:` header of each commit email. If the
	author ident of the commit is not textually identical to the
	provided `ident`, place a `From:` header in the body of the
	message with the original author. If no `ident` is given, use
	the committer ident.
+
Note that this option is only useful if you are actually sending the
emails and want to identify yourself as the sender, but retain the
original author (and `git am` will correctly pick up the in-body
header). Note also that `git send-email` already handles this
transformation for you, and this option should not be used if you are
feeding the result to `git send-email`.

--[no-]force-in-body-from::
	With the e-mail sender specified via the `--from` option, by
	default, an in-body "From:" to identify the real author of
	the commit is added at the top of the commit log message if
	the sender is different from the author.  With this option,
	the in-body "From:" is added even when the sender and the
	author have the same name and address, which may help if the
	mailing list software mangles the sender's identity.
	Defaults to the value of the `format.forceInBodyFrom`
	configuration variable.

--add-header=<header>::
	Add an arbitrary header to the email headers.  This is in addition
	to any configured headers, and may be used multiple times.
	For example, `--add-header="Organization: git-foo"`.
	The negated form `--no-add-header` discards *all* (`To:`,
	`Cc:`, and custom) headers added so far from config or command
	line.

--[no-]cover-letter::
	In addition to the patches, generate a cover letter file
	containing the branch description, shortlog and the overall diffstat.  You can
	fill in a description in the file before sending it out.

--encode-email-headers::
--no-encode-email-headers::
	Encode email headers that have non-ASCII characters with
	"Q-encoding" (described in RFC 2047), instead of outputting the
	headers verbatim. Defaults to the value of the
	`format.encodeEmailHeaders` configuration variable.

--interdiff=<previous>::
	As a reviewer aid, insert an interdiff into the cover letter,
	or as commentary of the lone patch of a 1-patch series, showing
	the differences between