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
of the patch series (but see the discussion of the `notes.rewrite`
configuration options in linkgit:git-notes[1] to use this workflow).
+
The default is `--no-notes`, unless the `format.notes` configuration is
set.

--[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
	number.

--signature-file=<file>::
	Works just like --signature except the signature is read from a file.

--suffix=.<sfx>::
	Instead of using `.patch` as the suffix for generated
	filenames, use specified suffix.  A common alternative is
	`--suffix=.txt`.  Leaving this empty will remove the `.patch`
	suffix.
+
Note that the leading character does not have to be a dot; for example,
you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`.

-q::
--quiet::
	Do not print the names of the generated files to standard output.

--no-binary::
	Do not output contents of changes in binary files, instead
	display a notice that those files changed.  Patches generated
	using this option cannot be applied properly, but they are
	still useful for code review.

--zero-commit::
  Output an all-zero hash in each patch's From header instead
  of the hash of the commit.

--[no-]base[=<commit>]::
	Record the base tree information to identify the state the
	patch series applies to.  See the BASE TREE INFORMATION section
	below for details. If <commit> is "auto", a base commit is
	automatically chosen. The `--no-base` option overrides a
	`format.useAutoBase` configuration.

--root::
	Treat the revision argument as a <revision-range>, even if it
	is just a single commit (that would normally be treated as a
	<since>).  Note that root commits included in the specified
	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,
defaults for the subject prefix and file suffix, number patches when
outputting more than one patch, add "To:" or "Cc:" headers, configure
attachments, change the patch output directory, and sign off patches
with configuration variables.

------------
[format]
	headers = "Organization: git-foo\n"
	subjectPrefix = CHANGE
	suffix = .txt
	numbered = auto
	to = <email>
	cc = <email>
	attach [ = mime-boundary-string ]
	signOff = true
	outputDirectory = <directory>
	coverLetter = auto
	coverFromDescription = auto
------------


DISCUSSION
----------

The patch produced by 'git format-patch' is in UNIX mailbox format,
with a fixed "magic" time stamp to indicate that the file is output
from format-patch rather than a real mailbox, like so:

------------
From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Tue, 13 Jul 2010 11:42:54 -0700
Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
 =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

arch/arm config files were slimmed down using a python script
(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)

Do the same for ia64 so we can have sleek & trim looking
...
------------

Typically it will be placed in a MUA's drafts folder, edited to add
timely commentary that should not go in the changelog after the three
dashes, and then sent as a message whose body, in our example, starts
with "arch/arm config files were...".  On the receiving end, readers
can save interesting patches in a UNIX mailbox and apply them with
linkgit:git-am[1].

When a patch is part of an ongoing discussion,