rebase: validate -C<n> and --whitespace=<mode> parameters early
[gitweb.git] / Documentation / git-format-patch.txt
index 9624c84a658c13758cd3b9de55f47d1e89f7b15d..aba4c5febeb7ef4248d50a638d0a8bd58f7d553b 100644 (file)
@@ -19,9 +19,13 @@ SYNOPSIS
                   [--start-number <n>] [--numbered-files]
                   [--in-reply-to=Message-Id] [--suffix=.<sfx>]
                   [--ignore-if-in-upstream]
-                  [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
+                  [--rfc] [--subject-prefix=Subject-Prefix]
+                  [(--reroll-count|-v) <n>]
                   [--to=<email>] [--cc=<email>]
                   [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
+                  [--interdiff=<previous>]
+                  [--range-diff=<previous> [--creation-factor=<percent>]]
+                  [--progress]
                   [<common diff options>]
                   [ <since> | <revision range> ]
 
@@ -45,7 +49,7 @@ There are two ways to specify which commits to operate on.
 
 The first rule takes precedence in the case of a single <commit>.  To
 apply the second rule, i.e., format everything since the beginning of
-history up until <commit>, use the '\--root' option: `git format-patch
+history up until <commit>, use the `--root` option: `git format-patch
 --root <commit>`.  If you want to format only <commit> itself, you
 can do this with `git format-patch -1 <commit>`.
 
@@ -172,6 +176,11 @@ will want to ensure that threading is disabled for `git send-email`.
        allows for useful naming of a patch series, and can be
        combined with the `--numbered` option.
 
+--rfc::
+       Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For
+       Comments"; use this when sending an experimental patch for
+       discussion rather than application.
+
 -v <n>::
 --reroll-count=<n>::
        Mark the series as the <n>-th iteration of the topic. The
@@ -221,6 +230,33 @@ feeding the result to `git send-email`.
        containing the branch description, shortlog and the overall diffstat.  You can
        fill in a description in the file before sending it out.
 
+--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 the previous version of the patch series and
+       the series currently being formatted. `previous` is a single revision
+       naming the tip of the previous series which shares a common base with
+       the series being formatted (for example `git format-patch
+       --cover-letter --interdiff=feature/v1 -3 feature/v2`).
+
+--range-diff=<previous>::
+       As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1])
+       into the cover letter, or as commentary of the lone patch of a
+       1-patch series, showing the differences between the previous
+       version of the patch series and the series currently being formatted.
+       `previous` can be a single revision naming the tip of the previous
+       series if it shares a common base with the series being formatted (for
+       example `git format-patch --cover-letter --range-diff=feature/v1 -3
+       feature/v2`), or a revision range if the two versions of the series are
+       disjoint (for example `git format-patch --cover-letter
+       --range-diff=feature/v1~3..feature/v1 -3 feature/v2`).
+
+--creation-factor=<percent>::
+       Used with `--range-diff`, tweak the heuristic which matches up commits
+       between the previous and current series of patches by adjusting the
+       creation/deletion cost fudge factor. See linkgit:git-range-diff[1])
+       for details.
+
 --notes[=<ref>]::
        Append the notes (see linkgit:git-notes[1]) for the commit
        after the three-dash line.
@@ -233,7 +269,7 @@ 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>::
+--[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
@@ -277,6 +313,9 @@ you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.
        range are always formatted as creation patches, independently
        of this flag.
 
+--progress::
+       Show progress reports on stderr as patches are generated.
+
 CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message,
@@ -551,7 +590,7 @@ series A, B, C, the history would be like:
 ................................................
 
 With `git format-patch --base=P -3 C` (or variants thereof, e.g. with
-`--cover-letter` of using `Z..C` instead of `-3 C` to specify the
+`--cover-letter` or using `Z..C` instead of `-3 C` to specify the
 range), the base tree information block is shown at the end of the
 first message the command outputs (either the first patch, or the
 cover letter), like this: