1Generating patches with -p 2-------------------------- 3 4When "git-diff-index", "git-diff-tree", or "git-diff-files" are run 5with a '-p' option, "git diff" without the '--raw' option, or 6"git log" with the "-p" option, they 7do not produce the output described above; instead they produce a 8patch file. You can customize the creation of such patches via the 9GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables. 10 11What the -p option produces is slightly different from the traditional 12diff format: 13 141. It is preceded with a "git diff" header that looks like this: 15 16 diff --git a/file1 b/file2 17+ 18The `a/` and `b/` filenames are the same unless rename/copy is 19involved. Especially, even for a creation or a deletion, 20`/dev/null` is _not_ used in place of the `a/` or `b/` filenames. 21+ 22When rename/copy is involved, `file1` and `file2` show the 23name of the source file of the rename/copy and the name of 24the file that rename/copy produces, respectively. 25 262. It is followed by one or more extended header lines: 27 28 old mode <mode> 29 new mode <mode> 30 deleted file mode <mode> 31 new file mode <mode> 32 copy from <path> 33 copy to <path> 34 rename from <path> 35 rename to <path> 36 similarity index <number> 37 dissimilarity index <number> 38 index <hash>..<hash> <mode> 39+ 40File modes are printed as 6-digit octal numbers including the file type 41and file permission bits. 42+ 43Path names in extended headers do not include the `a/` and `b/` prefixes. 44+ 45The similarity index is the percentage of unchanged lines, and 46the dissimilarity index is the percentage of changed lines. It 47is a rounded down integer, followed by a percent sign. The 48similarity index value of 100% is thus reserved for two equal 49files, while 100% dissimilarity means that no line from the old 50file made it into the new one. 51+ 52The index line includes the SHA-1 checksum before and after the change. 53The <mode> is included if the file mode does not change; otherwise, 54separate lines indicate the old and the new mode. 55 563. TAB, LF, double quote and backslash characters in pathnames 57 are represented as `\t`, `\n`, `\"` and `\\`, respectively. 58 If there is need for such substitution then the whole 59 pathname is put in double quotes. 60 614. All the `file1` files in the output refer to files before the 62 commit, and all the `file2` files refer to files after the commit. 63 It is incorrect to apply each change to each file sequentially. For 64 example, this patch will swap a and b: 65 66 diff --git a/a b/b 67 rename from a 68 rename to b 69 diff --git a/b b/a 70 rename from b 71 rename to a 72 73 74combined diff format 75-------------------- 76 77Any diff-generating command can take the `-c` or `--cc` option to 78produce a 'combined diff' when showing a merge. This is the default 79format when showing merges with linkgit:git-diff[1] or 80linkgit:git-show[1]. Note also that you can give the `-m' option to any 81of these commands to force generation of diffs with individual parents 82of a merge. 83 84A 'combined diff' format looks like this: 85 86------------ 87diff --combined describe.c 88index fabadb8,cc95eb0..4866510 89--- a/describe.c 90+++ b/describe.c 91@@@ -98,20 -98,12 +98,20 @@@ 92 return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; 93 } 94 95- static void describe(char *arg) 96 -static void describe(struct commit *cmit, int last_one) 97++static void describe(char *arg, int last_one) 98 { 99 + unsigned char sha1[20]; 100 + struct commit *cmit; 101 struct commit_list *list; 102 static int initialized = 0; 103 struct commit_name *n; 104 105 + if (get_sha1(arg, sha1) < 0) 106 + usage(describe_usage); 107 + cmit = lookup_commit_reference(sha1); 108 + if (!cmit) 109 + usage(describe_usage); 110 + 111 if (!initialized) { 112 initialized = 1; 113 for_each_ref(get_name); 114------------ 115 1161. It is preceded with a "git diff" header, that looks like 117 this (when '-c' option is used): 118 119 diff --combined file 120+ 121or like this (when '--cc' option is used): 122 123 diff --cc file 124 1252. It is followed by one or more extended header lines 126 (this example shows a merge with two parents): 127 128 index <hash>,<hash>..<hash> 129 mode <mode>,<mode>..<mode> 130 new file mode <mode> 131 deleted file mode <mode>,<mode> 132+ 133The `mode <mode>,<mode>..<mode>` line appears only if at least one of 134the <mode> is different from the rest. Extended headers with 135information about detected contents movement (renames and 136copying detection) are designed to work with diff of two 137<tree-ish> and are not used by combined diff format. 138 1393. It is followed by two-line from-file/to-file header 140 141 --- a/file 142 +++ b/file 143+ 144Similar to two-line header for traditional 'unified' diff 145format, `/dev/null` is used to signal created or deleted 146files. 147 1484. Chunk header format is modified to prevent people from 149 accidentally feeding it to `patch -p1`. Combined diff format 150 was created for review of merge commit changes, and was not 151 meant for apply. The change is similar to the change in the 152 extended 'index' header: 153 154 @@@ <from-file-range> <from-file-range> <to-file-range> @@@ 155+ 156There are (number of parents + 1) `@` characters in the chunk 157header for combined diff format. 158 159Unlike the traditional 'unified' diff format, which shows two 160files A and B with a single column that has `-` (minus -- 161appears in A but removed in B), `+` (plus -- missing in A but 162added to B), or `" "` (space -- unchanged) prefix, this format 163compares two or more files file1, file2,... with one file X, and 164shows how X differs from each of fileN. One column for each of 165fileN is prepended to the output line to note how X's line is 166different from it. 167 168A `-` character in the column N means that the line appears in 169fileN but it does not appear in the result. A `+` character 170in the column N means that the line appears in the result, 171and fileN does not have that line (in other words, the line was 172added, from the point of view of that parent). 173 174In the above example output, the function signature was changed 175from both files (hence two `-` removals from both file1 and 176file2, plus `++` to mean one line that was added does not appear 177in either file1 nor file2). Also eight other lines are the same 178from file1 but do not appear in file2 (hence prefixed with `{plus}`). 179 180When shown by `git diff-tree -c`, it compares the parents of a 181merge commit with the merge result (i.e. file1..fileN are the 182parents). When shown by `git diff-files -c`, it compares the 183two unresolved merge parents with the working tree file 184(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka 185"their version").