`--in-reply-to`, and the first patch mail, in this order.  'deep'
threading makes every mail a reply to the previous one.
+
The default is `--no-thread`, unless the `format.thread` configuration
is set.  `--thread` without an argument is equivalent to `--thread=shallow`.
+
Beware that the default for 'git send-email' is to thread emails
itself.  If you want `git format-patch` to take care of threading, you
will want to ensure that threading is disabled for `git send-email`.

--in-reply-to=<message-id>::
	Make the first mail (or all the mails with `--no-thread`) appear as a
	reply to the given <message-id>, which avoids breaking threads to
	provide a new patch series.

--ignore-if-in-upstream::
	Do not include a patch that matches a commit in
	<until>..<since>.  This will examine all patches reachable
	from <since> but not from <until> and compare them with the
	patches being generated, and any patch that matches is
	ignored.

--always::
	Include patches for commits that do not introduce any change,
	which are omitted by default.

--cover-from-description=<mode>::
	Controls which parts of the cover letter will be automatically
	populated using the branch's description.
+
If `<mode>` is `message` or `default`, the cover letter subject will be
populated with placeholder text. The body of the cover letter will be
populated with the branch's description. This is the default mode when
no configuration nor command line option is specified.
+
If `<mode>` is `subject`, the first paragraph of the branch description will
populate the cover letter subject. The remainder of the description will
populate the body of the cover letter.
+
If `<mode>` is `auto`, if the first paragraph of the branch description
is greater than 100 bytes, then the mode will be `message`, otherwise
`subject` will be used.
+
If `<mode>` is `none`, both the cover letter subject and body will be
populated with placeholder text.

--description-file=<file>::
	Use the contents of <file> instead of the branch's description
	for generating the cover letter.

--subject-prefix=<subject-prefix>::
	Instead of the standard '[PATCH]' prefix in the subject
	line, instead use '[<subject-prefix>]'. This can be used
	to name a patch series, and can be combined with the
	`--numbered` option.
+
The configuration variable `format.subjectPrefix` may also be used
to configure a subject prefix to apply to a given repository for
all patches. This is often useful on mailing lists which receive
patches for several repositories and can be used to disambiguate
the patches (with a value of e.g. "PATCH my-project").

--filename-max-length=<n>::
	Instead of the standard 64 bytes, chomp the generated output
	filenames at around '<n>' bytes (too short a value will be
	silently raised to a reasonable length).  Defaults to the
	value of the `format.filenameMaxLength` configuration
	variable, or 64 if unconfigured.

--rfc[=<rfc>]::
	Prepends the string _<rfc>_ (defaults to "RFC") to
	the subject prefix.  As the subject 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