]>
Commit | Line | Data |
---|---|---|
215a7ad1 JH |
1 | git-format-patch(1) |
2 | =================== | |
7fc9d69f JH |
3 | |
4 | NAME | |
5 | ---- | |
7bd7f280 | 6 | git-format-patch - Prepare patches for e-mail submission |
7fc9d69f JH |
7 | |
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
353ce815 | 11 | [verse] |
50710ce4 | 12 | 'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout] |
f693b7e9 | 13 | [--no-thread | --thread[=<style>]] |
50710ce4 SB |
14 | [(--attach|--inline)[=<boundary>] | --no-attach] |
15 | [-s | --signoff] | |
6622d9c7 | 16 | [--signature=<signature> | --no-signature] |
7022650f | 17 | [--signature-file=<file>] |
a5a27c79 DB |
18 | [-n | --numbered | -N | --no-numbered] |
19 | [--start-number <n>] [--numbered-files] | |
c1a6f21c | 20 | [--in-reply-to=<message id>] [--suffix=.<sfx>] |
552038e2 | 21 | [--ignore-if-in-upstream] [--always] |
bf8e65b3 | 22 | [--cover-from-description=<mode>] |
c1a6f21c | 23 | [--rfc] [--subject-prefix=<subject prefix>] |
68e83a5b | 24 | [(--reroll-count|-v) <n>] |
ae6c098f | 25 | [--to=<email>] [--cc=<email>] |
83d9db78 | 26 | [--[no-]cover-letter] [--quiet] |
19d097e3 | 27 | [--[no-]encode-email-headers] |
83d9db78 | 28 | [--no-notes | --notes[=<ref>]] |
126facf8 | 29 | [--interdiff=<previous>] |
8631bf1c | 30 | [--range-diff=<previous> [--creation-factor=<percent>]] |
3baf58bf | 31 | [--filename-max-length=<n>] |
738e88a2 | 32 | [--progress] |
50710ce4 | 33 | [<common diff options>] |
8a1d076e | 34 | [ <since> | <revision range> ] |
7fc9d69f JH |
35 | |
36 | DESCRIPTION | |
37 | ----------- | |
2052d146 | 38 | |
8e0601f5 | 39 | Prepare each non-merge commit with its "patch" in |
28e29ee3 | 40 | one "message" per commit, formatted to resemble a UNIX mailbox. |
2052d146 | 41 | The output of this command is convenient for e-mail submission or |
0b444cdb | 42 | for use with 'git am'. |
35ef3a4c | 43 | |
28e29ee3 JH |
44 | A "message" generated by the command consists of three parts: |
45 | ||
46 | * A brief metadata header that begins with `From <commit>` | |
47 | with a fixed `Mon Sep 17 00:00:00 2001` datestamp to help programs | |
48 | like "file(1)" to recognize that the file is an output from this | |
49 | command, fields that record the author identity, the author date, | |
50 | and the title of the change (taken from the first paragraph of the | |
51 | commit log message). | |
52 | ||
53 | * The second and subsequent paragraphs of the commit log message. | |
54 | ||
55 | * The "patch", which is the "diff -p --stat" output (see | |
56 | linkgit:git-diff[1]) between the commit and its parent. | |
57 | ||
ce14cc0b | 58 | The log message and the patch are separated by a line with a |
28e29ee3 JH |
59 | three-dash line. |
60 | ||
8a1d076e JH |
61 | There are two ways to specify which commits to operate on. |
62 | ||
63 | 1. A single commit, <since>, specifies that the commits leading | |
64 | to the tip of the current branch that are not in the history | |
65 | that leads to the <since> to be output. | |
66 | ||
67 | 2. Generic <revision range> expression (see "SPECIFYING | |
9d83e382 | 68 | REVISIONS" section in linkgit:gitrevisions[7]) means the |
2f6a3823 JH |
69 | commits in the specified range. |
70 | ||
2d266f9d TR |
71 | The first rule takes precedence in the case of a single <commit>. To |
72 | apply the second rule, i.e., format everything since the beginning of | |
9e9f132f | 73 | history up until <commit>, use the `--root` option: `git format-patch |
6cf378f0 | 74 | --root <commit>`. If you want to format only <commit> itself, you |
dce5ef14 | 75 | can do this with `git format-patch -1 <commit>`. |
8a1d076e | 76 | |
e6ff0f42 | 77 | By default, each output file is numbered sequentially from 1, and uses the |
2052d146 | 78 | first line of the commit message (massaged for pathname safety) as |
dce5ef14 | 79 | the filename. With the `--numbered-files` option, the output file names |
e6ff0f42 JL |
80 | will only be numbers, without the first line of the commit appended. |
81 | The names of the output files are printed to standard | |
dce5ef14 | 82 | output, unless the `--stdout` option is specified. |
66f04f38 | 83 | |
dce5ef14 | 84 | If `-o` is specified, output files are created in <dir>. Otherwise |
bc6bf2d7 | 85 | they are created in the current working directory. The default path |
ae9f6311 | 86 | can be set with the `format.outputDirectory` configuration option. |
bc6bf2d7 AK |
87 | The `-o` option takes precedence over `format.outputDirectory`. |
88 | To store patches in the current working directory even when | |
edefc318 BW |
89 | `format.outputDirectory` points elsewhere, use `-o .`. All directory |
90 | components will be created. | |
35ef3a4c | 91 | |
52ffe995 JW |
92 | By default, the subject of a single patch is "[PATCH] " followed by |
93 | the concatenation of lines from the commit message up to the first blank | |
94 | line (see the DISCUSSION section of linkgit:git-commit[1]). | |
95 | ||
96 | When multiple patches are output, the subject prefix will instead be | |
97 | "[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. | |
98 | To omit patch numbers from the subject, use `-N`. | |
35ef3a4c | 99 | |
dce5ef14 BG |
100 | If given `--thread`, `git-format-patch` will generate `In-Reply-To` and |
101 | `References` headers to make the second and subsequent patch mails appear | |
ba4324c4 | 102 | as replies to the first mail; this also generates a `Message-ID` header to |
cc35de84 | 103 | reference. |
7fc9d69f JH |
104 | |
105 | OPTIONS | |
106 | ------- | |
c1a95fa6 | 107 | :git-format-patch: 1 |
b8105375 BG |
108 | include::diff-options.txt[] |
109 | ||
ed5f07a6 | 110 | -<n>:: |
2c642ed8 | 111 | Prepare patches from the topmost <n> commits. |
ed5f07a6 | 112 | |
3240240f SB |
113 | -o <dir>:: |
114 | --output-directory <dir>:: | |
35ef3a4c | 115 | Use <dir> to store the resulting files, instead of the |
efd02016 | 116 | current working directory. |
35ef3a4c | 117 | |
3240240f SB |
118 | -n:: |
119 | --numbered:: | |
a567fdcb | 120 | Name output in '[PATCH n/m]' format, even with a single patch. |
35ef3a4c | 121 | |
3240240f SB |
122 | -N:: |
123 | --no-numbered:: | |
49604a4d BG |
124 | Name output in '[PATCH]' format. |
125 | ||
2052d146 DS |
126 | --start-number <n>:: |
127 | Start numbering the patches at <n> instead of 1. | |
128 | ||
e6ff0f42 JL |
129 | --numbered-files:: |
130 | Output file names will be a simple number sequence | |
131 | without the default first line of the commit appended. | |
e6ff0f42 | 132 | |
3240240f SB |
133 | -k:: |
134 | --keep-subject:: | |
35ef3a4c JH |
135 | Do not strip/add '[PATCH]' from the first line of the |
136 | commit log message. | |
137 | ||
3240240f SB |
138 | -s:: |
139 | --signoff:: | |
3abd4a67 | 140 | Add a `Signed-off-by` trailer to the commit message, using |
6f855371 | 141 | the committer identity of yourself. |
b2c150d3 | 142 | See the signoff option in linkgit:git-commit[1] for more information. |
6f855371 | 143 | |
54ba6013 | 144 | --stdout:: |
2052d146 DS |
145 | Print all commits to the standard output in mbox format, |
146 | instead of creating a file for each one. | |
7fc9d69f | 147 | |
c112f689 JS |
148 | --attach[=<boundary>]:: |
149 | Create multipart/mixed attachment, the first part of | |
150 | which is the commit message and the patch itself in the | |
dce5ef14 | 151 | second part, with `Content-Disposition: attachment`. |
c112f689 | 152 | |
0db5260b JW |
153 | --no-attach:: |
154 | Disable the creation of an attachment, overriding the | |
155 | configuration setting. | |
156 | ||
c112f689 JS |
157 | --inline[=<boundary>]:: |
158 | Create multipart/mixed attachment, the first part of | |
159 | which is the commit message and the patch itself in the | |
dce5ef14 | 160 | second part, with `Content-Disposition: inline`. |
a15a44ef | 161 | |
30984ed2 | 162 | --thread[=<style>]:: |
f693b7e9 | 163 | --no-thread:: |
dce5ef14 | 164 | Controls addition of `In-Reply-To` and `References` headers to |
f693b7e9 | 165 | make the second and subsequent mails appear as replies to the |
ba4324c4 | 166 | first. Also controls generation of the `Message-ID` header to |
f693b7e9 | 167 | reference. |
30984ed2 TR |
168 | + |
169 | The optional <style> argument can be either `shallow` or `deep`. | |
fd1ff306 | 170 | 'shallow' threading makes every mail a reply to the head of the |
30984ed2 | 171 | series, where the head is chosen from the cover letter, the |
6cf378f0 | 172 | `--in-reply-to`, and the first patch mail, in this order. 'deep' |
f693b7e9 YD |
173 | threading makes every mail a reply to the previous one. |
174 | + | |
ae9f6311 | 175 | The default is `--no-thread`, unless the `format.thread` configuration |
f0249131 | 176 | is set. `--thread` without an argument is equivalent to `--thread=shallow`. |
f693b7e9 YD |
177 | + |
178 | Beware that the default for 'git send-email' is to thread emails | |
dce5ef14 BG |
179 | itself. If you want `git format-patch` to take care of threading, you |
180 | will want to ensure that threading is disabled for `git send-email`. | |
28ffb898 | 181 | |
c1a6f21c | 182 | --in-reply-to=<message id>:: |
dce5ef14 | 183 | Make the first mail (or all the mails with `--no-thread`) appear as a |
c1a6f21c | 184 | reply to the given <message id>, which avoids breaking threads to |
da56645d JT |
185 | provide a new patch series. |
186 | ||
cc75ad67 DK |
187 | --ignore-if-in-upstream:: |
188 | Do not include a patch that matches a commit in | |
189 | <until>..<since>. This will examine all patches reachable | |
190 | from <since> but not from <until> and compare them with the | |
191 | patches being generated, and any patch that matches is | |
192 | ignored. | |
193 | ||
552038e2 A |
194 | --always:: |
195 | Include patches for commits that do not introduce any change, | |
196 | which are omitted by default. | |
197 | ||
bf8e65b3 DL |
198 | --cover-from-description=<mode>:: |
199 | Controls which parts of the cover letter will be automatically | |
200 | populated using the branch's description. | |
201 | + | |
202 | If `<mode>` is `message` or `default`, the cover letter subject will be | |
203 | populated with placeholder text. The body of the cover letter will be | |
204 | populated with the branch's description. This is the default mode when | |
205 | no configuration nor command line option is specified. | |
206 | + | |
207 | If `<mode>` is `subject`, the first paragraph of the branch description will | |
208 | populate the cover letter subject. The remainder of the description will | |
209 | populate the body of the cover letter. | |
210 | + | |
211 | If `<mode>` is `auto`, if the first paragraph of the branch description | |
212 | is greater than 100 bytes, then the mode will be `message`, otherwise | |
213 | `subject` will be used. | |
214 | + | |
215 | If `<mode>` is `none`, both the cover letter subject and body will be | |
216 | populated with placeholder text. | |
217 | ||
67f4b36e OB |
218 | --description-file=<file>:: |
219 | Use the contents of <file> instead of the branch's description | |
220 | for generating the cover letter. | |
221 | ||
c1a6f21c | 222 | --subject-prefix=<subject prefix>:: |
2d9e4a47 | 223 | Instead of the standard '[PATCH]' prefix in the subject |
e0d7db74 DD |
224 | line, instead use '[<subject prefix>]'. This can be used |
225 | to name a patch series, and can be combined with the | |
226 | `--numbered` option. | |
227 | + | |
228 | The configuration variable `format.subjectPrefix` may also be used | |
229 | to configure a subject prefix to apply to a given repository for | |
230 | all patches. This is often useful on mailing lists which receive | |
231 | patches for several repositories and can be used to disambiguate | |
232 | the patches (with a value of e.g. "PATCH my-project"). | |
2d9e4a47 | 233 | |
3baf58bf JH |
234 | --filename-max-length=<n>:: |
235 | Instead of the standard 64 bytes, chomp the generated output | |
236 | filenames at around '<n>' bytes (too short a value will be | |
237 | silently raised to a reasonable length). Defaults to the | |
238 | value of the `format.filenameMaxLength` configuration | |
239 | variable, or 64 if unconfigured. | |
240 | ||
68e83a5b | 241 | --rfc:: |
e0d7db74 DD |
242 | Prepends "RFC" to the subject prefix (producing "RFC PATCH" by |
243 | default). RFC means "Request For Comments"; use this when sending | |
244 | an experimental patch for discussion rather than application. | |
68e83a5b | 245 | |
7952ea66 | 246 | -v <n>:: |
4aad08e0 JH |
247 | --reroll-count=<n>:: |
248 | Mark the series as the <n>-th iteration of the topic. The | |
d614f075 | 249 | output filenames have `v<n>` prepended to them, and the |
4aad08e0 JH |
250 | subject prefix ("PATCH" by default, but configurable via the |
251 | `--subject-prefix` option) has ` v<n>` appended to it. E.g. | |
252 | `--reroll-count=4` may produce `v4-0001-add-makefile.patch` | |
253 | file that has "Subject: [PATCH v4 1/20] Add makefile" in it. | |
db91988a ZH |
254 | `<n>` does not have to be an integer (e.g. "--reroll-count=4.4", |
255 | or "--reroll-count=4rev2" are allowed), but the downside of | |
256 | using such a reroll-count is that the range-diff/interdiff | |
257 | with the previous version does not state exactly which | |
548afb0d | 258 | version the new iteration is compared against. |
4aad08e0 | 259 | |
ae6c098f SD |
260 | --to=<email>:: |
261 | Add a `To:` header to the email headers. This is in addition | |
262 | to any configured headers, and may be used multiple times. | |
b2cd17b9 TR |
263 | The negated form `--no-to` discards all `To:` headers added so |
264 | far (from config or command line). | |
ae6c098f | 265 | |
736cc67d | 266 | --cc=<email>:: |
dce5ef14 | 267 | Add a `Cc:` header to the email headers. This is in addition |
736cc67d | 268 | to any configured headers, and may be used multiple times. |
b2cd17b9 TR |
269 | The negated form `--no-cc` discards all `Cc:` headers added so |
270 | far (from config or command line). | |
736cc67d | 271 | |
a9080475 JK |
272 | --from:: |
273 | --from=<ident>:: | |
274 | Use `ident` in the `From:` header of each commit email. If the | |
275 | author ident of the commit is not textually identical to the | |
276 | provided `ident`, place a `From:` header in the body of the | |
277 | message with the original author. If no `ident` is given, use | |
278 | the committer ident. | |
279 | + | |
280 | Note that this option is only useful if you are actually sending the | |
281 | emails and want to identify yourself as the sender, but retain the | |
282 | original author (and `git am` will correctly pick up the in-body | |
283 | header). Note also that `git send-email` already handles this | |
284 | transformation for you, and this option should not be used if you are | |
285 | feeding the result to `git send-email`. | |
286 | ||
34bc1b10 JH |
287 | --[no-]force-in-body-from:: |
288 | With the e-mail sender specified via the `--from` option, by | |
289 | default, an in-body "From:" to identify the real author of | |
290 | the commit is added at the top of the commit log message if | |
291 | the sender is different from the author. With this option, | |
292 | the in-body "From:" is added even when the sender and the | |
293 | author have the same name and address, which may help if the | |
294 | mailing list software mangles the sender's identity. | |
d5fc07df JH |
295 | Defaults to the value of the `format.forceInBodyFrom` |
296 | configuration variable. | |
34bc1b10 | 297 | |
d7d9c2d0 MH |
298 | --add-header=<header>:: |
299 | Add an arbitrary header to the email headers. This is in addition | |
300 | to any configured headers, and may be used multiple times. | |
b2cd17b9 TR |
301 | For example, `--add-header="Organization: git-foo"`. |
302 | The negated form `--no-add-header` discards *all* (`To:`, | |
303 | `Cc:`, and custom) headers added so far from config or command | |
304 | line. | |
d7d9c2d0 | 305 | |
2a4c2607 | 306 | --[no-]cover-letter:: |
f4912391 | 307 | In addition to the patches, generate a cover letter file |
561d2b79 | 308 | containing the branch description, shortlog and the overall diffstat. You can |
f4912391 | 309 | fill in a description in the file before sending it out. |
a5a27c79 | 310 | |
19d097e3 EB |
311 | --encode-email-headers:: |
312 | --no-encode-email-headers:: | |
313 | Encode email headers that have non-ASCII characters with | |
314 | "Q-encoding" (described in RFC 2047), instead of outputting the | |
315 | headers verbatim. Defaults to the value of the | |
316 | `format.encodeEmailHeaders` configuration variable. | |
317 | ||
126facf8 | 318 | --interdiff=<previous>:: |
ee6cbf71 ES |
319 | As a reviewer aid, insert an interdiff into the cover letter, |
320 | or as commentary of the lone patch of a 1-patch series, showing | |
126facf8 ES |
321 | the differences between the previous version of the patch series and |
322 | the series currently being formatted. `previous` is a single revision | |
323 | naming the tip of the previous series which shares a common base with | |
324 | the series being formatted (for example `git format-patch | |
325 | --cover-letter --interdiff=feature/v1 -3 feature/v2`). | |
326 | ||
31e2617a ES |
327 | --range-diff=<previous>:: |
328 | As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1]) | |
40ce4160 ES |
329 | into the cover letter, or as commentary of the lone patch of a |
330 | 1-patch series, showing the differences between the previous | |
31e2617a | 331 | version of the patch series and the series currently being formatted. |
2e6fd71a ES |
332 | `previous` can be a single revision naming the tip of the previous |
333 | series if it shares a common base with the series being formatted (for | |
31e2617a | 334 | example `git format-patch --cover-letter --range-diff=feature/v1 -3 |
2e6fd71a ES |
335 | feature/v2`), or a revision range if the two versions of the series are |
336 | disjoint (for example `git format-patch --cover-letter | |
337 | --range-diff=feature/v1~3..feature/v1 -3 feature/v2`). | |
d8981c3f JH |
338 | + |
339 | Note that diff options passed to the command affect how the primary | |
340 | product of `format-patch` is generated, and they are not passed to | |
341 | the underlying `range-diff` machinery used to generate the cover-letter | |
342 | material (this may change in the future). | |
31e2617a | 343 | |
8631bf1c ES |
344 | --creation-factor=<percent>:: |
345 | Used with `--range-diff`, tweak the heuristic which matches up commits | |
346 | between the previous and current series of patches by adjusting the | |
347 | creation/deletion cost fudge factor. See linkgit:git-range-diff[1]) | |
348 | for details. | |
349 | ||
e422c0cf | 350 | --notes[=<ref>]:: |
83d9db78 | 351 | --no-notes:: |
e422c0cf JH |
352 | Append the notes (see linkgit:git-notes[1]) for the commit |
353 | after the three-dash line. | |
354 | + | |
355 | The expected use case of this is to write supporting explanation for | |
6454d9f1 PO |
356 | the commit that does not belong to the commit log message proper, |
357 | and include it with the patch submission. While one can simply write | |
358 | these explanations after `format-patch` has run but before sending, | |
2de9b711 | 359 | keeping them as Git notes allows them to be maintained between versions |
6454d9f1 PO |
360 | of the patch series (but see the discussion of the `notes.rewrite` |
361 | configuration options in linkgit:git-notes[1] to use this workflow). | |
13cdf780 DL |
362 | + |
363 | The default is `--no-notes`, unless the `format.notes` configuration is | |
364 | set. | |
e422c0cf | 365 | |
2c7ee986 | 366 | --[no-]signature=<signature>:: |
6622d9c7 SB |
367 | Add a signature to each message produced. Per RFC 3676 the signature |
368 | is separated from the body by a line with '-- ' on it. If the | |
2de9b711 | 369 | signature option is omitted the signature defaults to the Git version |
6622d9c7 SB |
370 | number. |
371 | ||
7022650f JM |
372 | --signature-file=<file>:: |
373 | Works just like --signature except the signature is read from a file. | |
374 | ||
03eeaeae | 375 | --suffix=.<sfx>:: |
917a8f89 | 376 | Instead of using `.patch` as the suffix for generated |
02783075 | 377 | filenames, use specified suffix. A common alternative is |
50710ce4 SB |
378 | `--suffix=.txt`. Leaving this empty will remove the `.patch` |
379 | suffix. | |
03eeaeae | 380 | + |
50710ce4 SB |
381 | Note that the leading character does not have to be a dot; for example, |
382 | you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. | |
03eeaeae | 383 | |
b7df098c | 384 | -q:: |
b781cfaf CMN |
385 | --quiet:: |
386 | Do not print the names of the generated files to standard output. | |
387 | ||
37c22a4b | 388 | --no-binary:: |
50710ce4 SB |
389 | Do not output contents of changes in binary files, instead |
390 | display a notice that those files changed. Patches generated | |
391 | using this option cannot be applied properly, but they are | |
392 | still useful for code review. | |
37c22a4b | 393 | |
3a30aa17 | 394 | --zero-commit:: |
395 | Output an all-zero hash in each patch's From header instead | |
396 | of the hash of the commit. | |
397 | ||
945dc55d | 398 | --[no-]base[=<commit>]:: |
fa2ab86d XY |
399 | Record the base tree information to identify the state the |
400 | patch series applies to. See the BASE TREE INFORMATION section | |
c1a6f21c | 401 | below for details. If <commit> is "auto", a base commit is |
945dc55d DL |
402 | automatically chosen. The `--no-base` option overrides a |
403 | `format.useAutoBase` configuration. | |
fa2ab86d | 404 | |
2d266f9d TR |
405 | --root:: |
406 | Treat the revision argument as a <revision range>, even if it | |
407 | is just a single commit (that would normally be treated as a | |
408 | <since>). Note that root commits included in the specified | |
409 | range are always formatted as creation patches, independently | |
410 | of this flag. | |
411 | ||
738e88a2 KW |
412 | --progress:: |
413 | Show progress reports on stderr as patches are generated. | |
414 | ||
96ce6d26 MM |
415 | CONFIGURATION |
416 | ------------- | |
50710ce4 SB |
417 | You can specify extra mail header lines to be added to each message, |
418 | defaults for the subject prefix and file suffix, number patches when | |
c1a6f21c DL |
419 | outputting more than one patch, add "To:" or "Cc:" headers, configure |
420 | attachments, change the patch output directory, and sign off patches | |
421 | with configuration variables. | |
96ce6d26 | 422 | |
917a8f89 | 423 | ------------ |
96ce6d26 | 424 | [format] |
7f9d77f2 | 425 | headers = "Organization: git-foo\n" |
da0005b8 | 426 | subjectPrefix = CHANGE |
7f9d77f2 JN |
427 | suffix = .txt |
428 | numbered = auto | |
ae6c098f | 429 | to = <email> |
fe8928e6 | 430 | cc = <email> |
0db5260b | 431 | attach [ = mime-boundary-string ] |
da0005b8 | 432 | signOff = true |
c1a6f21c DL |
433 | outputDirectory = <directory> |
434 | coverLetter = auto | |
bf8e65b3 | 435 | coverFromDescription = auto |
917a8f89 | 436 | ------------ |
03eeaeae | 437 | |
96ce6d26 | 438 | |
e0d48279 JN |
439 | DISCUSSION |
440 | ---------- | |
441 | ||
442 | The patch produced by 'git format-patch' is in UNIX mailbox format, | |
443 | with a fixed "magic" time stamp to indicate that the file is output | |
444 | from format-patch rather than a real mailbox, like so: | |
445 | ||
446 | ------------ | |
447 | From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001 | |
448 | From: Tony Luck <tony.luck@intel.com> | |
449 | Date: Tue, 13 Jul 2010 11:42:54 -0700 | |
450 | Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?= | |
451 | =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?= | |
452 | MIME-Version: 1.0 | |
453 | Content-Type: text/plain; charset=UTF-8 | |
454 | Content-Transfer-Encoding: 8bit | |
455 | ||
456 | arch/arm config files were slimmed down using a python script | |
457 | (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment) | |
458 | ||
459 | Do the same for ia64 so we can have sleek & trim looking | |
460 | ... | |
461 | ------------ | |
462 | ||
463 | Typically it will be placed in a MUA's drafts folder, edited to add | |
464 | timely commentary that should not go in the changelog after the three | |
465 | dashes, and then sent as a message whose body, in our example, starts | |
466 | with "arch/arm config files were...". On the receiving end, readers | |
467 | can save interesting patches in a UNIX mailbox and apply them with | |
468 | linkgit:git-am[1]. | |
469 | ||
470 | When a patch is part of an ongoing discussion, the patch generated by | |
471 | 'git format-patch' can be tweaked to take advantage of the 'git am | |
472 | --scissors' feature. After your response to the discussion comes a | |
473 | line that consists solely of "`-- >8 --`" (scissors and perforation), | |
474 | followed by the patch with unnecessary header fields removed: | |
475 | ||
476 | ------------ | |
477 | ... | |
478 | > So we should do such-and-such. | |
479 | ||
480 | Makes sense to me. How about this patch? | |
481 | ||
482 | -- >8 -- | |
483 | Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet | |
484 | ||
485 | arch/arm config files were slimmed down using a python script | |
486 | ... | |
487 | ------------ | |
488 | ||
489 | When sending a patch this way, most often you are sending your own | |
490 | patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you | |
491 | should omit `From:` and `Date:` lines from the patch file. The patch | |
492 | title is likely to be different from the subject of the discussion the | |
493 | patch is in response to, so it is likely that you would want to keep | |
494 | the Subject: line, like the example above. | |
495 | ||
57756161 JN |
496 | Checking for patch corruption |
497 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
498 | Many mailers if not set up properly will corrupt whitespace. Here are | |
499 | two common types of corruption: | |
500 | ||
501 | * Empty context lines that do not have _any_ whitespace. | |
502 | ||
503 | * Non-empty context lines that have one extra whitespace at the | |
504 | beginning. | |
505 | ||
506 | One way to test if your MUA is set up correctly is: | |
507 | ||
508 | * Send the patch to yourself, exactly the way you would, except | |
509 | with To: and Cc: lines that do not contain the list and | |
510 | maintainer address. | |
511 | ||
512 | * Save that patch to a file in UNIX mailbox format. Call it a.patch, | |
513 | say. | |
514 | ||
515 | * Apply it: | |
516 | ||
517 | $ git fetch <project> master:test-apply | |
328c6cb8 | 518 | $ git switch test-apply |
80f537f7 | 519 | $ git restore --source=HEAD --staged --worktree :/ |
57756161 JN |
520 | $ git am a.patch |
521 | ||
522 | If it does not apply correctly, there can be various reasons. | |
523 | ||
524 | * The patch itself does not apply cleanly. That is _bad_ but | |
525 | does not have much to do with your MUA. You might want to rebase | |
526 | the patch with linkgit:git-rebase[1] before regenerating it in | |
527 | this case. | |
528 | ||
529 | * The MUA corrupted your patch; "am" would complain that | |
530 | the patch does not apply. Look in the .git/rebase-apply/ subdirectory and | |
531 | see what 'patch' file contains and check for the common | |
532 | corruption patterns mentioned above. | |
533 | ||
534 | * While at it, check the 'info' and 'final-commit' files as well. | |
535 | If what is in 'final-commit' is not exactly what you would want to | |
536 | see in the commit log message, it is very likely that the | |
537 | receiver would end up hand editing the log message when applying | |
538 | your patch. Things like "Hi, this is my first patch.\n" in the | |
539 | patch e-mail should come after the three-dash line that signals | |
540 | the end of the commit message. | |
541 | ||
dc53151f JN |
542 | MUA-SPECIFIC HINTS |
543 | ------------------ | |
544 | Here are some hints on how to successfully submit patches inline using | |
545 | various mailers. | |
546 | ||
36c10e6d JN |
547 | GMail |
548 | ~~~~~ | |
549 | GMail does not have any way to turn off line wrapping in the web | |
550 | interface, so it will mangle any emails that you send. You can however | |
551 | use "git send-email" and send your patches through the GMail SMTP server, or | |
552 | use any IMAP email client to connect to the google IMAP server and forward | |
553 | the emails through that. | |
554 | ||
555 | For hints on using 'git send-email' to send your patches through the | |
556 | GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1]. | |
557 | ||
558 | For hints on submission using the IMAP interface, see the EXAMPLE | |
559 | section of linkgit:git-imap-send[1]. | |
560 | ||
dc53151f JN |
561 | Thunderbird |
562 | ~~~~~~~~~~~ | |
563 | By default, Thunderbird will both wrap emails as well as flag | |
564 | them as being 'format=flowed', both of which will make the | |
2de9b711 | 565 | resulting email unusable by Git. |
dc53151f | 566 | |
b8959605 JS |
567 | There are three different approaches: use an add-on to turn off line wraps, |
568 | configure Thunderbird to not mangle patches, or use | |
dc53151f JN |
569 | an external editor to keep Thunderbird from mangling the patches. |
570 | ||
b8959605 JS |
571 | Approach #1 (add-on) |
572 | ^^^^^^^^^^^^^^^^^^^^ | |
573 | ||
574 | Install the Toggle Word Wrap add-on that is available from | |
575 | https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ | |
576 | It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu | |
577 | that you can tick off. Now you can compose the message as you otherwise do | |
578 | (cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to | |
579 | insert line breaks manually in any text that you type. | |
580 | ||
581 | Approach #2 (configuration) | |
dc53151f JN |
582 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
583 | Three steps: | |
584 | ||
585 | 1. Configure your mail server composition as plain text: | |
586 | Edit...Account Settings...Composition & Addressing, | |
587 | uncheck "Compose Messages in HTML". | |
588 | ||
589 | 2. Configure your general composition window to not wrap. | |
590 | + | |
591 | In Thunderbird 2: | |
592 | Edit..Preferences..Composition, wrap plain text messages at 0 | |
593 | + | |
594 | In Thunderbird 3: | |
595 | Edit..Preferences..Advanced..Config Editor. Search for | |
596 | "mail.wrap_long_lines". | |
f737684d RJ |
597 | Toggle it to make sure it is set to `false`. Also, search for |
598 | "mailnews.wraplength" and set the value to 0. | |
dc53151f JN |
599 | |
600 | 3. Disable the use of format=flowed: | |
ba170517 JNA |
601 | Edit..Preferences..Advanced..Config Editor. Search for |
602 | "mailnews.send_plaintext_flowed". | |
603 | Toggle it to make sure it is set to `false`. | |
dc53151f JN |
604 | |
605 | After that is done, you should be able to compose email as you | |
606 | otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc), | |
607 | and the patches will not be mangled. | |
608 | ||
b8959605 | 609 | Approach #3 (external editor) |
dc53151f JN |
610 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
611 | ||
612 | The following Thunderbird extensions are needed: | |
65175d9e JS |
613 | AboutConfig from https://mjg.github.io/AboutConfig/ and |
614 | External Editor from https://globs.org/articles.php?lng=en&pg=8 | |
dc53151f JN |
615 | |
616 | 1. Prepare the patch as a text file using your method of choice. | |
617 | ||
618 | 2. Before opening a compose window, use Edit->Account Settings to | |
619 | uncheck the "Compose messages in HTML format" setting in the | |
620 | "Composition & Addressing" panel of the account to be used to | |
621 | send the patch. | |
622 | ||
623 | 3. In the main Thunderbird window, 'before' you open the compose | |
624 | window for the patch, use Tools->about:config to set the | |
625 | following to the indicated values: | |
626 | + | |
627 | ---------- | |
628 | mailnews.send_plaintext_flowed => false | |
629 | mailnews.wraplength => 0 | |
630 | ---------- | |
631 | ||
632 | 4. Open a compose window and click the external editor icon. | |
633 | ||
634 | 5. In the external editor window, read in the patch file and exit | |
635 | the editor normally. | |
636 | ||
637 | Side note: it may be possible to do step 2 with | |
638 | about:config and the following settings but no one's tried yet. | |
639 | ||
640 | ---------- | |
641 | mail.html_compose => false | |
642 | mail.identity.default.compose_html => false | |
643 | mail.identity.id?.compose_html => false | |
644 | ---------- | |
645 | ||
646 | There is a script in contrib/thunderbird-patch-inline which can help | |
647 | you include patches with Thunderbird in an easy way. To use it, do the | |
648 | steps above and then use the script as the external editor. | |
649 | ||
967ab8ef JN |
650 | KMail |
651 | ~~~~~ | |
652 | This should help you to submit patches inline using KMail. | |
653 | ||
654 | 1. Prepare the patch as a text file. | |
655 | ||
656 | 2. Click on New Mail. | |
657 | ||
658 | 3. Go under "Options" in the Composer window and be sure that | |
659 | "Word wrap" is not set. | |
660 | ||
661 | 4. Use Message -> Insert file... and insert the patch. | |
662 | ||
663 | 5. Back in the compose window: add whatever other text you wish to the | |
664 | message, complete the addressing and subject fields, and press send. | |
665 | ||
fa2ab86d XY |
666 | BASE TREE INFORMATION |
667 | --------------------- | |
668 | ||
669 | The base tree information block is used for maintainers or third party | |
670 | testers to know the exact state the patch series applies to. It consists | |
671 | of the 'base commit', which is a well-known commit that is part of the | |
672 | stable part of the project history everybody else works off of, and zero | |
673 | or more 'prerequisite patches', which are well-known patches in flight | |
674 | that is not yet part of the 'base commit' that need to be applied on top | |
675 | of 'base commit' in topological order before the patches can be applied. | |
676 | ||
677 | The 'base commit' is shown as "base-commit: " followed by the 40-hex of | |
678 | the commit object name. A 'prerequisite patch' is shown as | |
679 | "prerequisite-patch-id: " followed by the 40-hex 'patch id', which can | |
680 | be obtained by passing the patch through the `git patch-id --stable` | |
681 | command. | |
682 | ||
683 | Imagine that on top of the public commit P, you applied well-known | |
684 | patches X, Y and Z from somebody else, and then built your three-patch | |
685 | series A, B, C, the history would be like: | |
686 | ||
687 | ................................................ | |
688 | ---P---X---Y---Z---A---B---C | |
689 | ................................................ | |
690 | ||
691 | With `git format-patch --base=P -3 C` (or variants thereof, e.g. with | |
7ba1ceef | 692 | `--cover-letter` or using `Z..C` instead of `-3 C` to specify the |
fa2ab86d XY |
693 | range), the base tree information block is shown at the end of the |
694 | first message the command outputs (either the first patch, or the | |
695 | cover letter), like this: | |
696 | ||
697 | ------------ | |
698 | base-commit: P | |
699 | prerequisite-patch-id: X | |
700 | prerequisite-patch-id: Y | |
701 | prerequisite-patch-id: Z | |
702 | ------------ | |
703 | ||
704 | For non-linear topology, such as | |
705 | ||
706 | ................................................ | |
707 | ---P---X---A---M---C | |
708 | \ / | |
709 | Y---Z---B | |
710 | ................................................ | |
711 | ||
712 | You can also use `git format-patch --base=P -3 C` to generate patches | |
713 | for A, B and C, and the identifiers for P, X, Y, Z are appended at the | |
714 | end of the first message. | |
e0d48279 | 715 | |
203eb838 JH |
716 | If set `--base=auto` in cmdline, it will automatically compute |
717 | the base commit as the merge base of tip commit of the remote-tracking | |
3de66517 | 718 | branch and revision-range specified in cmdline. |
203eb838 | 719 | For a local branch, you need to make it to track a remote branch by `git branch |
3de66517 XY |
720 | --set-upstream-to` before using this option. |
721 | ||
28ffb898 JH |
722 | EXAMPLES |
723 | -------- | |
724 | ||
921177f5 | 725 | * Extract commits between revisions R1 and R2, and apply them on top of |
ba170517 | 726 | the current branch using 'git am' to cherry-pick them: |
921177f5 CC |
727 | + |
728 | ------------ | |
467c0197 | 729 | $ git format-patch -k --stdout R1..R2 | git am -3 -k |
921177f5 CC |
730 | ------------ |
731 | ||
732 | * Extract all commits which are in the current branch but not in the | |
ba170517 | 733 | origin branch: |
921177f5 CC |
734 | + |
735 | ------------ | |
736 | $ git format-patch origin | |
737 | ------------ | |
738 | + | |
739 | For each commit a separate file is created in the current directory. | |
740 | ||
741 | * Extract all commits that lead to 'origin' since the inception of the | |
ba170517 | 742 | project: |
921177f5 CC |
743 | + |
744 | ------------ | |
9c67c757 | 745 | $ git format-patch --root origin |
921177f5 CC |
746 | ------------ |
747 | ||
748 | * The same as the previous one: | |
749 | + | |
750 | ------------ | |
751 | $ git format-patch -M -B origin | |
752 | ------------ | |
753 | + | |
754 | Additionally, it detects and handles renames and complete rewrites | |
755 | intelligently to produce a renaming patch. A renaming patch reduces | |
50710ce4 | 756 | the amount of text output, and generally makes it easier to review. |
2de9b711 TA |
757 | Note that non-Git "patch" programs won't understand renaming patches, so |
758 | use it only when you know the recipient uses Git to apply your patch. | |
921177f5 CC |
759 | |
760 | * Extract three topmost commits from the current branch and format them | |
ba170517 | 761 | as e-mailable patches: |
921177f5 CC |
762 | + |
763 | ------------ | |
764 | $ git format-patch -3 | |
765 | ------------ | |
28ffb898 | 766 | |
8e0601f5 JK |
767 | CAVEATS |
768 | ------- | |
769 | ||
770 | Note that `format-patch` will omit merge commits from the output, even | |
771 | if they are part of the requested range. A simple "patch" does not | |
772 | include enough information for the receiving end to reproduce the same | |
773 | merge commit. | |
774 | ||
56ae8df5 | 775 | SEE ALSO |
28ffb898 | 776 | -------- |
5162e697 | 777 | linkgit:git-am[1], linkgit:git-send-email[1] |
28ffb898 | 778 | |
7fc9d69f JH |
779 | GIT |
780 | --- | |
9e1f0a85 | 781 | Part of the linkgit:git[1] suite |