[--start-number <n>] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
- [--subject-prefix=Subject-Prefix]
+ [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
- [--cover-letter] [--quiet] [--notes[=<ref>]]
+ [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
[<common diff options>]
[ <since> | <revision range> ]
allows for useful naming of a patch series, and can be
combined with the `--numbered` option.
+-v <n>::
+--reroll-count=<n>::
+ Mark the series as the <n>-th iteration of the topic. The
+ output filenames have `v<n>` pretended 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.
+
--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-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`.
+
--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.
`Cc:`, and custom) headers added so far from config or command
line.
---cover-letter::
+--[no-]cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
fill in a description in the file before sending it out.
the commit that does not belong to the commit log message proper,
and include it with the patch submission. While one can simply write
these explanations after `format-patch` has run but before sending,
-keeping them as git notes allows them to be maintained between versions
+keeping them as Git notes allows them to be maintained between versions
of the patch series (but see the discussion of the `notes.rewrite`
configuration options in linkgit:git-notes[1] to use this workflow).
--[no]-signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
is separated from the body by a line with '-- ' on it. If the
- signature option is omitted the signature defaults to the git version
+ signature option is omitted the signature defaults to the Git version
number.
--suffix=.<sfx>::
cc = <email>
attach [ = mime-boundary-string ]
signoff = true
+ coverletter = auto
------------
~~~~~~~~~~~
By default, Thunderbird will both wrap emails as well as flag
them as being 'format=flowed', both of which will make the
-resulting email unusable by git.
+resulting email unusable by Git.
There are three different approaches: use an add-on to turn off line wraps,
configure Thunderbird to not mangle patches, or use
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
the amount of text output, and generally makes it easier to review.
-Note that non-git "patch" programs won't understand renaming patches, so
-use it only when you know the recipient uses git to apply your patch.
+Note that non-Git "patch" programs won't understand renaming patches, so
+use it only when you know the recipient uses Git to apply your patch.
* Extract three topmost commits from the current branch and format them
as e-mailable patches: