]>
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] |
a5a27c79 DB |
17 | [-n | --numbered | -N | --no-numbered] |
18 | [--start-number <n>] [--numbered-files] | |
19 | [--in-reply-to=Message-Id] [--suffix=.<sfx>] | |
20 | [--ignore-if-in-upstream] | |
21 | [--subject-prefix=Subject-Prefix] | |
ae6c098f | 22 | [--to=<email>] [--cc=<email>] |
a5a27c79 | 23 | [--cover-letter] |
50710ce4 | 24 | [<common diff options>] |
8a1d076e | 25 | [ <since> | <revision range> ] |
7fc9d69f JH |
26 | |
27 | DESCRIPTION | |
28 | ----------- | |
2052d146 | 29 | |
8a1d076e | 30 | Prepare each commit with its patch in |
2052d146 | 31 | one file per commit, formatted to resemble UNIX mailbox format. |
2052d146 | 32 | The output of this command is convenient for e-mail submission or |
0b444cdb | 33 | for use with 'git am'. |
35ef3a4c | 34 | |
8a1d076e JH |
35 | There are two ways to specify which commits to operate on. |
36 | ||
37 | 1. A single commit, <since>, specifies that the commits leading | |
38 | to the tip of the current branch that are not in the history | |
39 | that leads to the <since> to be output. | |
40 | ||
41 | 2. Generic <revision range> expression (see "SPECIFYING | |
9d83e382 | 42 | REVISIONS" section in linkgit:gitrevisions[7]) means the |
2f6a3823 JH |
43 | commits in the specified range. |
44 | ||
2d266f9d TR |
45 | The first rule takes precedence in the case of a single <commit>. To |
46 | apply the second rule, i.e., format everything since the beginning of | |
dce5ef14 BG |
47 | history up until <commit>, use the '\--root' option: `git format-patch |
48 | \--root <commit>`. If you want to format only <commit> itself, you | |
49 | can do this with `git format-patch -1 <commit>`. | |
8a1d076e | 50 | |
e6ff0f42 | 51 | By default, each output file is numbered sequentially from 1, and uses the |
2052d146 | 52 | first line of the commit message (massaged for pathname safety) as |
dce5ef14 | 53 | the filename. With the `--numbered-files` option, the output file names |
e6ff0f42 JL |
54 | will only be numbers, without the first line of the commit appended. |
55 | The names of the output files are printed to standard | |
dce5ef14 | 56 | output, unless the `--stdout` option is specified. |
66f04f38 | 57 | |
dce5ef14 | 58 | If `-o` is specified, output files are created in <dir>. Otherwise |
2052d146 | 59 | they are created in the current working directory. |
35ef3a4c | 60 | |
a567fdcb BG |
61 | By default, the subject of a single patch is "[PATCH] First Line" and |
62 | the subject when multiple patches are output is "[PATCH n/m] First | |
dce5ef14 BG |
63 | Line". To force 1/1 to be added for a single patch, use `-n`. To omit |
64 | patch numbers from the subject, use `-N`. | |
35ef3a4c | 65 | |
dce5ef14 BG |
66 | If given `--thread`, `git-format-patch` will generate `In-Reply-To` and |
67 | `References` headers to make the second and subsequent patch mails appear | |
68 | as replies to the first mail; this also generates a `Message-Id` header to | |
cc35de84 | 69 | reference. |
7fc9d69f JH |
70 | |
71 | OPTIONS | |
72 | ------- | |
c1a95fa6 | 73 | :git-format-patch: 1 |
b8105375 BG |
74 | include::diff-options.txt[] |
75 | ||
ed5f07a6 | 76 | -<n>:: |
2c642ed8 | 77 | Prepare patches from the topmost <n> commits. |
ed5f07a6 | 78 | |
3240240f SB |
79 | -o <dir>:: |
80 | --output-directory <dir>:: | |
35ef3a4c | 81 | Use <dir> to store the resulting files, instead of the |
efd02016 | 82 | current working directory. |
35ef3a4c | 83 | |
3240240f SB |
84 | -n:: |
85 | --numbered:: | |
a567fdcb | 86 | Name output in '[PATCH n/m]' format, even with a single patch. |
35ef3a4c | 87 | |
3240240f SB |
88 | -N:: |
89 | --no-numbered:: | |
49604a4d BG |
90 | Name output in '[PATCH]' format. |
91 | ||
2052d146 DS |
92 | --start-number <n>:: |
93 | Start numbering the patches at <n> instead of 1. | |
94 | ||
e6ff0f42 JL |
95 | --numbered-files:: |
96 | Output file names will be a simple number sequence | |
97 | without the default first line of the commit appended. | |
e6ff0f42 | 98 | |
3240240f SB |
99 | -k:: |
100 | --keep-subject:: | |
35ef3a4c JH |
101 | Do not strip/add '[PATCH]' from the first line of the |
102 | commit log message. | |
103 | ||
3240240f SB |
104 | -s:: |
105 | --signoff:: | |
6f855371 NW |
106 | Add `Signed-off-by:` line to the commit message, using |
107 | the committer identity of yourself. | |
108 | ||
54ba6013 | 109 | --stdout:: |
2052d146 DS |
110 | Print all commits to the standard output in mbox format, |
111 | instead of creating a file for each one. | |
7fc9d69f | 112 | |
c112f689 JS |
113 | --attach[=<boundary>]:: |
114 | Create multipart/mixed attachment, the first part of | |
115 | which is the commit message and the patch itself in the | |
dce5ef14 | 116 | second part, with `Content-Disposition: attachment`. |
c112f689 | 117 | |
0db5260b JW |
118 | --no-attach:: |
119 | Disable the creation of an attachment, overriding the | |
120 | configuration setting. | |
121 | ||
c112f689 JS |
122 | --inline[=<boundary>]:: |
123 | Create multipart/mixed attachment, the first part of | |
124 | which is the commit message and the patch itself in the | |
dce5ef14 | 125 | second part, with `Content-Disposition: inline`. |
a15a44ef | 126 | |
30984ed2 | 127 | --thread[=<style>]:: |
f693b7e9 | 128 | --no-thread:: |
dce5ef14 | 129 | Controls addition of `In-Reply-To` and `References` headers to |
f693b7e9 | 130 | make the second and subsequent mails appear as replies to the |
dce5ef14 | 131 | first. Also controls generation of the `Message-Id` header to |
f693b7e9 | 132 | reference. |
30984ed2 TR |
133 | + |
134 | The optional <style> argument can be either `shallow` or `deep`. | |
fd1ff306 | 135 | 'shallow' threading makes every mail a reply to the head of the |
30984ed2 | 136 | series, where the head is chosen from the cover letter, the |
fd1ff306 | 137 | `\--in-reply-to`, and the first patch mail, in this order. 'deep' |
f693b7e9 YD |
138 | threading makes every mail a reply to the previous one. |
139 | + | |
dce5ef14 BG |
140 | The default is `--no-thread`, unless the 'format.thread' configuration |
141 | is set. If `--thread` is specified without a style, it defaults to the | |
f693b7e9 YD |
142 | style specified by 'format.thread' if any, or else `shallow`. |
143 | + | |
144 | Beware that the default for 'git send-email' is to thread emails | |
dce5ef14 BG |
145 | itself. If you want `git format-patch` to take care of threading, you |
146 | will want to ensure that threading is disabled for `git send-email`. | |
28ffb898 | 147 | |
da56645d | 148 | --in-reply-to=Message-Id:: |
dce5ef14 | 149 | Make the first mail (or all the mails with `--no-thread`) appear as a |
da56645d JT |
150 | reply to the given Message-Id, which avoids breaking threads to |
151 | provide a new patch series. | |
152 | ||
cc75ad67 DK |
153 | --ignore-if-in-upstream:: |
154 | Do not include a patch that matches a commit in | |
155 | <until>..<since>. This will examine all patches reachable | |
156 | from <since> but not from <until> and compare them with the | |
157 | patches being generated, and any patch that matches is | |
158 | ignored. | |
159 | ||
2d9e4a47 RJ |
160 | --subject-prefix=<Subject-Prefix>:: |
161 | Instead of the standard '[PATCH]' prefix in the subject | |
162 | line, instead use '[<Subject-Prefix>]'. This | |
163 | allows for useful naming of a patch series, and can be | |
dce5ef14 | 164 | combined with the `--numbered` option. |
2d9e4a47 | 165 | |
ae6c098f SD |
166 | --to=<email>:: |
167 | Add a `To:` header to the email headers. This is in addition | |
168 | to any configured headers, and may be used multiple times. | |
169 | ||
736cc67d | 170 | --cc=<email>:: |
dce5ef14 | 171 | Add a `Cc:` header to the email headers. This is in addition |
736cc67d DB |
172 | to any configured headers, and may be used multiple times. |
173 | ||
d7d9c2d0 MH |
174 | --add-header=<header>:: |
175 | Add an arbitrary header to the email headers. This is in addition | |
176 | to any configured headers, and may be used multiple times. | |
dce5ef14 | 177 | For example, `--add-header="Organization: git-foo"` |
d7d9c2d0 | 178 | |
a5a27c79 | 179 | --cover-letter:: |
f4912391 MM |
180 | In addition to the patches, generate a cover letter file |
181 | containing the shortlog and the overall diffstat. You can | |
182 | fill in a description in the file before sending it out. | |
a5a27c79 | 183 | |
6622d9c7 SB |
184 | --[no]-signature=<signature>:: |
185 | Add a signature to each message produced. Per RFC 3676 the signature | |
186 | is separated from the body by a line with '-- ' on it. If the | |
187 | signature option is omitted the signature defaults to the git version | |
188 | number. | |
189 | ||
03eeaeae | 190 | --suffix=.<sfx>:: |
917a8f89 | 191 | Instead of using `.patch` as the suffix for generated |
02783075 | 192 | filenames, use specified suffix. A common alternative is |
50710ce4 SB |
193 | `--suffix=.txt`. Leaving this empty will remove the `.patch` |
194 | suffix. | |
03eeaeae | 195 | + |
50710ce4 SB |
196 | Note that the leading character does not have to be a dot; for example, |
197 | you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. | |
03eeaeae | 198 | |
37c22a4b | 199 | --no-binary:: |
50710ce4 SB |
200 | Do not output contents of changes in binary files, instead |
201 | display a notice that those files changed. Patches generated | |
202 | using this option cannot be applied properly, but they are | |
203 | still useful for code review. | |
37c22a4b | 204 | |
2d266f9d TR |
205 | --root:: |
206 | Treat the revision argument as a <revision range>, even if it | |
207 | is just a single commit (that would normally be treated as a | |
208 | <since>). Note that root commits included in the specified | |
209 | range are always formatted as creation patches, independently | |
210 | of this flag. | |
211 | ||
96ce6d26 MM |
212 | CONFIGURATION |
213 | ------------- | |
50710ce4 SB |
214 | You can specify extra mail header lines to be added to each message, |
215 | defaults for the subject prefix and file suffix, number patches when | |
ae6c098f SD |
216 | outputting more than one patch, add "To" or "Cc:" headers, configure |
217 | attachments, and sign off patches with configuration variables. | |
96ce6d26 | 218 | |
917a8f89 | 219 | ------------ |
96ce6d26 | 220 | [format] |
7f9d77f2 JN |
221 | headers = "Organization: git-foo\n" |
222 | subjectprefix = CHANGE | |
223 | suffix = .txt | |
224 | numbered = auto | |
ae6c098f | 225 | to = <email> |
fe8928e6 | 226 | cc = <email> |
0db5260b | 227 | attach [ = mime-boundary-string ] |
1d1876e9 | 228 | signoff = true |
917a8f89 | 229 | ------------ |
03eeaeae | 230 | |
96ce6d26 | 231 | |
e0d48279 JN |
232 | DISCUSSION |
233 | ---------- | |
234 | ||
235 | The patch produced by 'git format-patch' is in UNIX mailbox format, | |
236 | with a fixed "magic" time stamp to indicate that the file is output | |
237 | from format-patch rather than a real mailbox, like so: | |
238 | ||
239 | ------------ | |
240 | From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001 | |
241 | From: Tony Luck <tony.luck@intel.com> | |
242 | Date: Tue, 13 Jul 2010 11:42:54 -0700 | |
243 | Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?= | |
244 | =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?= | |
245 | MIME-Version: 1.0 | |
246 | Content-Type: text/plain; charset=UTF-8 | |
247 | Content-Transfer-Encoding: 8bit | |
248 | ||
249 | arch/arm config files were slimmed down using a python script | |
250 | (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment) | |
251 | ||
252 | Do the same for ia64 so we can have sleek & trim looking | |
253 | ... | |
254 | ------------ | |
255 | ||
256 | Typically it will be placed in a MUA's drafts folder, edited to add | |
257 | timely commentary that should not go in the changelog after the three | |
258 | dashes, and then sent as a message whose body, in our example, starts | |
259 | with "arch/arm config files were...". On the receiving end, readers | |
260 | can save interesting patches in a UNIX mailbox and apply them with | |
261 | linkgit:git-am[1]. | |
262 | ||
263 | When a patch is part of an ongoing discussion, the patch generated by | |
264 | 'git format-patch' can be tweaked to take advantage of the 'git am | |
265 | --scissors' feature. After your response to the discussion comes a | |
266 | line that consists solely of "`-- >8 --`" (scissors and perforation), | |
267 | followed by the patch with unnecessary header fields removed: | |
268 | ||
269 | ------------ | |
270 | ... | |
271 | > So we should do such-and-such. | |
272 | ||
273 | Makes sense to me. How about this patch? | |
274 | ||
275 | -- >8 -- | |
276 | Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet | |
277 | ||
278 | arch/arm config files were slimmed down using a python script | |
279 | ... | |
280 | ------------ | |
281 | ||
282 | When sending a patch this way, most often you are sending your own | |
283 | patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you | |
284 | should omit `From:` and `Date:` lines from the patch file. The patch | |
285 | title is likely to be different from the subject of the discussion the | |
286 | patch is in response to, so it is likely that you would want to keep | |
287 | the Subject: line, like the example above. | |
288 | ||
57756161 JN |
289 | Checking for patch corruption |
290 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
291 | Many mailers if not set up properly will corrupt whitespace. Here are | |
292 | two common types of corruption: | |
293 | ||
294 | * Empty context lines that do not have _any_ whitespace. | |
295 | ||
296 | * Non-empty context lines that have one extra whitespace at the | |
297 | beginning. | |
298 | ||
299 | One way to test if your MUA is set up correctly is: | |
300 | ||
301 | * Send the patch to yourself, exactly the way you would, except | |
302 | with To: and Cc: lines that do not contain the list and | |
303 | maintainer address. | |
304 | ||
305 | * Save that patch to a file in UNIX mailbox format. Call it a.patch, | |
306 | say. | |
307 | ||
308 | * Apply it: | |
309 | ||
310 | $ git fetch <project> master:test-apply | |
311 | $ git checkout test-apply | |
312 | $ git reset --hard | |
313 | $ git am a.patch | |
314 | ||
315 | If it does not apply correctly, there can be various reasons. | |
316 | ||
317 | * The patch itself does not apply cleanly. That is _bad_ but | |
318 | does not have much to do with your MUA. You might want to rebase | |
319 | the patch with linkgit:git-rebase[1] before regenerating it in | |
320 | this case. | |
321 | ||
322 | * The MUA corrupted your patch; "am" would complain that | |
323 | the patch does not apply. Look in the .git/rebase-apply/ subdirectory and | |
324 | see what 'patch' file contains and check for the common | |
325 | corruption patterns mentioned above. | |
326 | ||
327 | * While at it, check the 'info' and 'final-commit' files as well. | |
328 | If what is in 'final-commit' is not exactly what you would want to | |
329 | see in the commit log message, it is very likely that the | |
330 | receiver would end up hand editing the log message when applying | |
331 | your patch. Things like "Hi, this is my first patch.\n" in the | |
332 | patch e-mail should come after the three-dash line that signals | |
333 | the end of the commit message. | |
334 | ||
dc53151f JN |
335 | MUA-SPECIFIC HINTS |
336 | ------------------ | |
337 | Here are some hints on how to successfully submit patches inline using | |
338 | various mailers. | |
339 | ||
36c10e6d JN |
340 | GMail |
341 | ~~~~~ | |
342 | GMail does not have any way to turn off line wrapping in the web | |
343 | interface, so it will mangle any emails that you send. You can however | |
344 | use "git send-email" and send your patches through the GMail SMTP server, or | |
345 | use any IMAP email client to connect to the google IMAP server and forward | |
346 | the emails through that. | |
347 | ||
348 | For hints on using 'git send-email' to send your patches through the | |
349 | GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1]. | |
350 | ||
351 | For hints on submission using the IMAP interface, see the EXAMPLE | |
352 | section of linkgit:git-imap-send[1]. | |
353 | ||
dc53151f JN |
354 | Thunderbird |
355 | ~~~~~~~~~~~ | |
356 | By default, Thunderbird will both wrap emails as well as flag | |
357 | them as being 'format=flowed', both of which will make the | |
358 | resulting email unusable by git. | |
359 | ||
360 | There are two different approaches. One approach is to configure | |
361 | Thunderbird to not mangle patches. The second approach is to use | |
362 | an external editor to keep Thunderbird from mangling the patches. | |
363 | ||
364 | Approach #1 (configuration) | |
365 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
366 | Three steps: | |
367 | ||
368 | 1. Configure your mail server composition as plain text: | |
369 | Edit...Account Settings...Composition & Addressing, | |
370 | uncheck "Compose Messages in HTML". | |
371 | ||
372 | 2. Configure your general composition window to not wrap. | |
373 | + | |
374 | In Thunderbird 2: | |
375 | Edit..Preferences..Composition, wrap plain text messages at 0 | |
376 | + | |
377 | In Thunderbird 3: | |
378 | Edit..Preferences..Advanced..Config Editor. Search for | |
379 | "mail.wrap_long_lines". | |
380 | Toggle it to make sure it is set to `false`. | |
381 | ||
382 | 3. Disable the use of format=flowed: | |
383 | Edit..Preferences..Advanced..Config Editor. Search for | |
384 | "mailnews.send_plaintext_flowed". | |
385 | Toggle it to make sure it is set to `false`. | |
386 | ||
387 | After that is done, you should be able to compose email as you | |
388 | otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc), | |
389 | and the patches will not be mangled. | |
390 | ||
391 | Approach #2 (external editor) | |
392 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
393 | ||
394 | The following Thunderbird extensions are needed: | |
395 | AboutConfig from http://aboutconfig.mozdev.org/ and | |
396 | External Editor from http://globs.org/articles.php?lng=en&pg=8 | |
397 | ||
398 | 1. Prepare the patch as a text file using your method of choice. | |
399 | ||
400 | 2. Before opening a compose window, use Edit->Account Settings to | |
401 | uncheck the "Compose messages in HTML format" setting in the | |
402 | "Composition & Addressing" panel of the account to be used to | |
403 | send the patch. | |
404 | ||
405 | 3. In the main Thunderbird window, 'before' you open the compose | |
406 | window for the patch, use Tools->about:config to set the | |
407 | following to the indicated values: | |
408 | + | |
409 | ---------- | |
410 | mailnews.send_plaintext_flowed => false | |
411 | mailnews.wraplength => 0 | |
412 | ---------- | |
413 | ||
414 | 4. Open a compose window and click the external editor icon. | |
415 | ||
416 | 5. In the external editor window, read in the patch file and exit | |
417 | the editor normally. | |
418 | ||
419 | Side note: it may be possible to do step 2 with | |
420 | about:config and the following settings but no one's tried yet. | |
421 | ||
422 | ---------- | |
423 | mail.html_compose => false | |
424 | mail.identity.default.compose_html => false | |
425 | mail.identity.id?.compose_html => false | |
426 | ---------- | |
427 | ||
428 | There is a script in contrib/thunderbird-patch-inline which can help | |
429 | you include patches with Thunderbird in an easy way. To use it, do the | |
430 | steps above and then use the script as the external editor. | |
431 | ||
967ab8ef JN |
432 | KMail |
433 | ~~~~~ | |
434 | This should help you to submit patches inline using KMail. | |
435 | ||
436 | 1. Prepare the patch as a text file. | |
437 | ||
438 | 2. Click on New Mail. | |
439 | ||
440 | 3. Go under "Options" in the Composer window and be sure that | |
441 | "Word wrap" is not set. | |
442 | ||
443 | 4. Use Message -> Insert file... and insert the patch. | |
444 | ||
445 | 5. Back in the compose window: add whatever other text you wish to the | |
446 | message, complete the addressing and subject fields, and press send. | |
447 | ||
e0d48279 | 448 | |
28ffb898 JH |
449 | EXAMPLES |
450 | -------- | |
451 | ||
921177f5 | 452 | * Extract commits between revisions R1 and R2, and apply them on top of |
0b444cdb | 453 | the current branch using 'git am' to cherry-pick them: |
921177f5 CC |
454 | + |
455 | ------------ | |
467c0197 | 456 | $ git format-patch -k --stdout R1..R2 | git am -3 -k |
921177f5 CC |
457 | ------------ |
458 | ||
459 | * Extract all commits which are in the current branch but not in the | |
460 | origin branch: | |
461 | + | |
462 | ------------ | |
463 | $ git format-patch origin | |
464 | ------------ | |
465 | + | |
466 | For each commit a separate file is created in the current directory. | |
467 | ||
468 | * Extract all commits that lead to 'origin' since the inception of the | |
469 | project: | |
470 | + | |
471 | ------------ | |
9c67c757 | 472 | $ git format-patch --root origin |
921177f5 CC |
473 | ------------ |
474 | ||
475 | * The same as the previous one: | |
476 | + | |
477 | ------------ | |
478 | $ git format-patch -M -B origin | |
479 | ------------ | |
480 | + | |
481 | Additionally, it detects and handles renames and complete rewrites | |
482 | intelligently to produce a renaming patch. A renaming patch reduces | |
50710ce4 SB |
483 | the amount of text output, and generally makes it easier to review. |
484 | Note that non-git "patch" programs won't understand renaming patches, so | |
921177f5 CC |
485 | use it only when you know the recipient uses git to apply your patch. |
486 | ||
487 | * Extract three topmost commits from the current branch and format them | |
488 | as e-mailable patches: | |
489 | + | |
490 | ------------ | |
491 | $ git format-patch -3 | |
492 | ------------ | |
28ffb898 | 493 | |
56ae8df5 | 494 | SEE ALSO |
28ffb898 | 495 | -------- |
5162e697 | 496 | linkgit:git-am[1], linkgit:git-send-email[1] |
28ffb898 | 497 | |
7fc9d69f JH |
498 | GIT |
499 | --- | |
9e1f0a85 | 500 | Part of the linkgit:git[1] suite |