wish to the
   message, complete the addressing and subject fields, and press send.

BASE TREE INFORMATION
---------------------

The base tree information block is used for maintainers or third party
testers to know the exact state the patch series applies to. It consists
of the 'base commit', which is a well-known commit that is part of the
stable part of the project history everybody else works off of, and zero
or more 'prerequisite patches', which are well-known patches in flight
that is not yet part of the 'base commit' that need to be applied on top
of 'base commit' in topological order before the patches can be applied.

The 'base commit' is shown as "base-commit: " followed by the 40-hex of
the commit object name.  A 'prerequisite patch' is shown as
"prerequisite-patch-id: " followed by the 40-hex 'patch id', which can
be obtained by passing the patch through the `git patch-id --stable`
command.

Imagine that on top of the public commit P, you applied well-known
patches X, Y and Z from somebody else, and then built your three-patch
series A, B, C, the history would be like:

................................................
---P---X---Y---Z---A---B---C
................................................

With `git format-patch --base=P -3 C` (or variants thereof, e.g. with
`--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:

------------
base-commit: P
prerequisite-patch-id: X
prerequisite-patch-id: Y
prerequisite-patch-id: Z
------------

For non-linear topology, such as

................................................
---P---X---A---M---C
    \         /
     Y---Z---B
................................................

You can also use `git format-patch --base=P -3 C` to generate patches
for A, B and C, and the identifiers for P, X, Y, Z are appended at the
end of the first message.

If set `--base=auto` in cmdline, it will automatically compute
the base commit as the merge base of tip commit of the remote-tracking
branch and revision-range specified in cmdline.
For a local branch, you need to make it to track a remote branch by `git branch
--set-upstream-to` before using this option.

EXAMPLES
--------

* Extract commits between revisions R1 and R2, and apply them on top of
  the current branch using 'git am' to cherry-pick them:
+
------------
$ git format-patch -k --stdout R1..R2 | git am -3 -k
------------

* Extract all commits which are in the current branch but not in the
  origin branch:
+
------------
$ git format-patch origin
------------
+
For each commit a separate file is created in the current directory.

* Extract all commits that lead to 'origin' since the inception of the
  project:
+
------------
$ git format-patch --root origin
------------

* The same as the previous one:
+
------------
$ git format-patch -M -B origin
------------
+
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.

* Extract three topmost commits from the current branch and format them
  as e-mailable patches:
+
------------
$ git format-patch -3
------------

CAVEATS
-------

Note that `format-patch` will omit merge commits from the output, even
if they are part of the requested range. A simple "patch" does not
include enough information for the receiving end to reproduce the same
merge commit.

SEE ALSO
--------
linkgit:git-am[1], linkgit:git-send-email[1]

GIT
---
Part of the linkgit:git[1] suite