summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 86f7780)
raw | patch | inline | side by side (parent: 86f7780)
author | Dennis Stosberg <dennis@stosberg.net> | |
Wed, 31 May 2006 14:14:08 +0000 (16:14 +0200) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Sat, 3 Jun 2006 01:17:08 +0000 (18:17 -0700) |
[jc: adjusted for recently resurrected features]
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-format-patch.txt | patch | blob | history |
index 7cc7fafc1d7fbe380ffa53e0d028886e15d0010e..493cac22dbe16dd5bdb9eed8f91f93ea184fa622 100644 (file)
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
- [--diff-options] <his> [<mine>]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach]
+ [-s | --signoff] [--diff-options] [--start-number <n>]
+ <since>[..<until>]
DESCRIPTION
-----------
-Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch formatted to resemble UNIX mailbox
-format, for e-mail submission or use with gitlink:git-am[1].
+
+Prepare each commit between <since> and <until> with its patch in
+one file per commit, formatted to resemble UNIX mailbox format.
+If ..<until> is not specified, the head of the current working
+tree is implied.
+
+The output of this command is convenient for e-mail submission or
+for use with gitlink:git-am[1].
Each output file is numbered sequentially from 1, and uses the
-first line of the commit message (massaged for pathname safety)
-as the filename.
+first line of the commit message (massaged for pathname safety) as
+the filename. The names of the output files are printed to standard
+output, unless the --stdout option is specified.
-When -o is specified, output files are created in <dir>; otherwise
-they are created in the current working directory. This option
-is ignored if --stdout is specified.
+If -o is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory.
-When -n is specified, instead of "[PATCH] Subject", the first
-line is formatted as "[PATCH N/M] Subject", unless you have only
-one patch.
+If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
OPTIONS
-------
-o|--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
- current working directory.
+ current working directory. This option is ignored if
+ --stdout is specified.
-n|--numbered::
Name output in '[PATCH n/m]' format.
+--start-number <n>::
+ Start numbering the patches at <n> instead of 1.
+
-k|--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
Add `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
--c|--check::
- Display suspicious lines in the patch. The definition
- of 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character.
-
--stdout::
- This flag generates the mbox formatted output to the
- standard output, instead of saving them into a file per
- patch and implies --mbox.
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
--attach::
Create attachments instead of inlining patches.
cherry-pick them.
git-format-patch origin::
- Extract commits the current branch accumulated since it
- pulled from origin the last time in a patch form for
- e-mail submission.
+ Extract all commits which are in the current branch but
+ not in the origin branch. For each commit a separate file
+ is created in the current directory.
git-format-patch -M -B origin::
- The same as the previous one, except detect and handle
- renames and complete rewrites intelligently to produce
- renaming patch. A renaming patch reduces the amount of
- text output, and generally makes it easier to review
- it. Note that the "patch" program does not understand
- renaming patch well, so use it only when you know the
- recipient uses git to apply your patch.
+ The same as the previous one. 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 it. Note that the "patch" program does not
+ understand renaming patches, so use it only when you know
+ the recipient uses git to apply your patch.
See Also