]>
Commit | Line | Data |
---|---|---|
1 | git-format-patch(1) | |
2 | =================== | |
3 | ||
4 | NAME | |
5 | ---- | |
6 | git-format-patch - Prepare patches for e-mail submission | |
7 | ||
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
11 | [verse] | |
12 | 'git format-patch' [-k] [(-o|--output-directory) <dir> | --stdout] | |
13 | [--no-thread | --thread[=<style>]] | |
14 | [(--attach|--inline)[=<boundary>] | --no-attach] | |
15 | [-s | --signoff] | |
16 | [--signature=<signature> | --no-signature] | |
17 | [--signature-file=<file>] | |
18 | [-n | --numbered | -N | --no-numbered] | |
19 | [--start-number <n>] [--numbered-files] | |
20 | [--in-reply-to=Message-Id] [--suffix=.<sfx>] | |
21 | [--ignore-if-in-upstream] | |
22 | [--rfc] [--subject-prefix=Subject-Prefix] | |
23 | [(--reroll-count|-v) <n>] | |
24 | [--to=<email>] [--cc=<email>] | |
25 | [--[no-]cover-letter] [--quiet] [--notes[=<ref>]] | |
26 | [--interdiff=<previous>] | |
27 | [--range-diff=<previous>] | |
28 | [--progress] | |
29 | [<common diff options>] | |
30 | [ <since> | <revision range> ] | |
31 | ||
32 | DESCRIPTION | |
33 | ----------- | |
34 | ||
35 | Prepare each commit with its patch in | |
36 | one file per commit, formatted to resemble UNIX mailbox format. | |
37 | The output of this command is convenient for e-mail submission or | |
38 | for use with 'git am'. | |
39 | ||
40 | There are two ways to specify which commits to operate on. | |
41 | ||
42 | 1. A single commit, <since>, specifies that the commits leading | |
43 | to the tip of the current branch that are not in the history | |
44 | that leads to the <since> to be output. | |
45 | ||
46 | 2. Generic <revision range> expression (see "SPECIFYING | |
47 | REVISIONS" section in linkgit:gitrevisions[7]) means the | |
48 | commits in the specified range. | |
49 | ||
50 | The first rule takes precedence in the case of a single <commit>. To | |
51 | apply the second rule, i.e., format everything since the beginning of | |
52 | history up until <commit>, use the `--root` option: `git format-patch | |
53 | --root <commit>`. If you want to format only <commit> itself, you | |
54 | can do this with `git format-patch -1 <commit>`. | |
55 | ||
56 | By default, each output file is numbered sequentially from 1, and uses the | |
57 | first line of the commit message (massaged for pathname safety) as | |
58 | the filename. With the `--numbered-files` option, the output file names | |
59 | will only be numbers, without the first line of the commit appended. | |
60 | The names of the output files are printed to standard | |
61 | output, unless the `--stdout` option is specified. | |
62 | ||
63 | If `-o` is specified, output files are created in <dir>. Otherwise | |
64 | they are created in the current working directory. The default path | |
65 | can be set with the `format.outputDirectory` configuration option. | |
66 | The `-o` option takes precedence over `format.outputDirectory`. | |
67 | To store patches in the current working directory even when | |
68 | `format.outputDirectory` points elsewhere, use `-o .`. | |
69 | ||
70 | By default, the subject of a single patch is "[PATCH] " followed by | |
71 | the concatenation of lines from the commit message up to the first blank | |
72 | line (see the DISCUSSION section of linkgit:git-commit[1]). | |
73 | ||
74 | When multiple patches are output, the subject prefix will instead be | |
75 | "[PATCH n/m] ". To force 1/1 to be added for a single patch, use `-n`. | |
76 | To omit patch numbers from the subject, use `-N`. | |
77 | ||
78 | If given `--thread`, `git-format-patch` will generate `In-Reply-To` and | |
79 | `References` headers to make the second and subsequent patch mails appear | |
80 | as replies to the first mail; this also generates a `Message-Id` header to | |
81 | reference. | |
82 | ||
83 | OPTIONS | |
84 | ------- | |
85 | :git-format-patch: 1 | |
86 | include::diff-options.txt[] | |
87 | ||
88 | -<n>:: | |
89 | Prepare patches from the topmost <n> commits. | |
90 | ||
91 | -o <dir>:: | |
92 | --output-directory <dir>:: | |
93 | Use <dir> to store the resulting files, instead of the | |
94 | current working directory. | |
95 | ||
96 | -n:: | |
97 | --numbered:: | |
98 | Name output in '[PATCH n/m]' format, even with a single patch. | |
99 | ||
100 | -N:: | |
101 | --no-numbered:: | |
102 | Name output in '[PATCH]' format. | |
103 | ||
104 | --start-number <n>:: | |
105 | Start numbering the patches at <n> instead of 1. | |
106 | ||
107 | --numbered-files:: | |
108 | Output file names will be a simple number sequence | |
109 | without the default first line of the commit appended. | |
110 | ||
111 | -k:: | |
112 | --keep-subject:: | |
113 | Do not strip/add '[PATCH]' from the first line of the | |
114 | commit log message. | |
115 | ||
116 | -s:: | |
117 | --signoff:: | |
118 | Add `Signed-off-by:` line to the commit message, using | |
119 | the committer identity of yourself. | |
120 | See the signoff option in linkgit:git-commit[1] for more information. | |
121 | ||
122 | --stdout:: | |
123 | Print all commits to the standard output in mbox format, | |
124 | instead of creating a file for each one. | |
125 | ||
126 | --attach[=<boundary>]:: | |
127 | Create multipart/mixed attachment, the first part of | |
128 | which is the commit message and the patch itself in the | |
129 | second part, with `Content-Disposition: attachment`. | |
130 | ||
131 | --no-attach:: | |
132 | Disable the creation of an attachment, overriding the | |
133 | configuration setting. | |
134 | ||
135 | --inline[=<boundary>]:: | |
136 | Create multipart/mixed attachment, the first part of | |
137 | which is the commit message and the patch itself in the | |
138 | second part, with `Content-Disposition: inline`. | |
139 | ||
140 | --thread[=<style>]:: | |
141 | --no-thread:: | |
142 | Controls addition of `In-Reply-To` and `References` headers to | |
143 | make the second and subsequent mails appear as replies to the | |
144 | first. Also controls generation of the `Message-Id` header to | |
145 | reference. | |
146 | + | |
147 | The optional <style> argument can be either `shallow` or `deep`. | |
148 | 'shallow' threading makes every mail a reply to the head of the | |
149 | series, where the head is chosen from the cover letter, the | |
150 | `--in-reply-to`, and the first patch mail, in this order. 'deep' | |
151 | threading makes every mail a reply to the previous one. | |
152 | + | |
153 | The default is `--no-thread`, unless the `format.thread` configuration | |
154 | is set. If `--thread` is specified without a style, it defaults to the | |
155 | style specified by `format.thread` if any, or else `shallow`. | |
156 | + | |
157 | Beware that the default for 'git send-email' is to thread emails | |
158 | itself. If you want `git format-patch` to take care of threading, you | |
159 | will want to ensure that threading is disabled for `git send-email`. | |
160 | ||
161 | --in-reply-to=Message-Id:: | |
162 | Make the first mail (or all the mails with `--no-thread`) appear as a | |
163 | reply to the given Message-Id, which avoids breaking threads to | |
164 | provide a new patch series. | |
165 | ||
166 | --ignore-if-in-upstream:: | |
167 | Do not include a patch that matches a commit in | |
168 | <until>..<since>. This will examine all patches reachable | |
169 | from <since> but not from <until> and compare them with the | |
170 | patches being generated, and any patch that matches is | |
171 | ignored. | |
172 | ||
173 | --subject-prefix=<Subject-Prefix>:: | |
174 | Instead of the standard '[PATCH]' prefix in the subject | |
175 | line, instead use '[<Subject-Prefix>]'. This | |
176 | allows for useful naming of a patch series, and can be | |
177 | combined with the `--numbered` option. | |
178 | ||
179 | --rfc:: | |
180 | Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For | |
181 | Comments"; use this when sending an experimental patch for | |
182 | discussion rather than application. | |
183 | ||
184 | -v <n>:: | |
185 | --reroll-count=<n>:: | |
186 | Mark the series as the <n>-th iteration of the topic. The | |
187 | output filenames have `v<n>` prepended to them, and the | |
188 | subject prefix ("PATCH" by default, but configurable via the | |
189 | `--subject-prefix` option) has ` v<n>` appended to it. E.g. | |
190 | `--reroll-count=4` may produce `v4-0001-add-makefile.patch` | |
191 | file that has "Subject: [PATCH v4 1/20] Add makefile" in it. | |
192 | ||
193 | --to=<email>:: | |
194 | Add a `To:` header to the email headers. This is in addition | |
195 | to any configured headers, and may be used multiple times. | |
196 | The negated form `--no-to` discards all `To:` headers added so | |
197 | far (from config or command line). | |
198 | ||
199 | --cc=<email>:: | |
200 | Add a `Cc:` header to the email headers. This is in addition | |
201 | to any configured headers, and may be used multiple times. | |
202 | The negated form `--no-cc` discards all `Cc:` headers added so | |
203 | far (from config or command line). | |
204 | ||
205 | --from:: | |
206 | --from=<ident>:: | |
207 | Use `ident` in the `From:` header of each commit email. If the | |
208 | author ident of the commit is not textually identical to the | |
209 | provided `ident`, place a `From:` header in the body of the | |
210 | message with the original author. If no `ident` is given, use | |
211 | the committer ident. | |
212 | + | |
213 | Note that this option is only useful if you are actually sending the | |
214 | emails and want to identify yourself as the sender, but retain the | |
215 | original author (and `git am` will correctly pick up the in-body | |
216 | header). Note also that `git send-email` already handles this | |
217 | transformation for you, and this option should not be used if you are | |
218 | feeding the result to `git send-email`. | |
219 | ||
220 | --add-header=<header>:: | |
221 | Add an arbitrary header to the email headers. This is in addition | |
222 | to any configured headers, and may be used multiple times. | |
223 | For example, `--add-header="Organization: git-foo"`. | |
224 | The negated form `--no-add-header` discards *all* (`To:`, | |
225 | `Cc:`, and custom) headers added so far from config or command | |
226 | line. | |
227 | ||
228 | --[no-]cover-letter:: | |
229 | In addition to the patches, generate a cover letter file | |
230 | containing the branch description, shortlog and the overall diffstat. You can | |
231 | fill in a description in the file before sending it out. | |
232 | ||
233 | --interdiff=<previous>:: | |
234 | As a reviewer aid, insert an interdiff into the cover letter, | |
235 | or as commentary of the lone patch of a 1-patch series, showing | |
236 | the differences between the previous version of the patch series and | |
237 | the series currently being formatted. `previous` is a single revision | |
238 | naming the tip of the previous series which shares a common base with | |
239 | the series being formatted (for example `git format-patch | |
240 | --cover-letter --interdiff=feature/v1 -3 feature/v2`). | |
241 | ||
242 | --range-diff=<previous>:: | |
243 | As a reviewer aid, insert a range-diff (see linkgit:git-range-diff[1]) | |
244 | into the cover letter showing the differences between the previous | |
245 | version of the patch series and the series currently being formatted. | |
246 | `previous` can be a single revision naming the tip of the previous | |
247 | series if it shares a common base with the series being formatted (for | |
248 | example `git format-patch --cover-letter --range-diff=feature/v1 -3 | |
249 | feature/v2`), or a revision range if the two versions of the series are | |
250 | disjoint (for example `git format-patch --cover-letter | |
251 | --range-diff=feature/v1~3..feature/v1 -3 feature/v2`). | |
252 | ||
253 | --notes[=<ref>]:: | |
254 | Append the notes (see linkgit:git-notes[1]) for the commit | |
255 | after the three-dash line. | |
256 | + | |
257 | The expected use case of this is to write supporting explanation for | |
258 | the commit that does not belong to the commit log message proper, | |
259 | and include it with the patch submission. While one can simply write | |
260 | these explanations after `format-patch` has run but before sending, | |
261 | keeping them as Git notes allows them to be maintained between versions | |
262 | of the patch series (but see the discussion of the `notes.rewrite` | |
263 | configuration options in linkgit:git-notes[1] to use this workflow). | |
264 | ||
265 | --[no-]signature=<signature>:: | |
266 | Add a signature to each message produced. Per RFC 3676 the signature | |
267 | is separated from the body by a line with '-- ' on it. If the | |
268 | signature option is omitted the signature defaults to the Git version | |
269 | number. | |
270 | ||
271 | --signature-file=<file>:: | |
272 | Works just like --signature except the signature is read from a file. | |
273 | ||
274 | --suffix=.<sfx>:: | |
275 | Instead of using `.patch` as the suffix for generated | |
276 | filenames, use specified suffix. A common alternative is | |
277 | `--suffix=.txt`. Leaving this empty will remove the `.patch` | |
278 | suffix. | |
279 | + | |
280 | Note that the leading character does not have to be a dot; for example, | |
281 | you can use `--suffix=-patch` to get `0001-description-of-my-change-patch`. | |
282 | ||
283 | -q:: | |
284 | --quiet:: | |
285 | Do not print the names of the generated files to standard output. | |
286 | ||
287 | --no-binary:: | |
288 | Do not output contents of changes in binary files, instead | |
289 | display a notice that those files changed. Patches generated | |
290 | using this option cannot be applied properly, but they are | |
291 | still useful for code review. | |
292 | ||
293 | --zero-commit:: | |
294 | Output an all-zero hash in each patch's From header instead | |
295 | of the hash of the commit. | |
296 | ||
297 | --base=<commit>:: | |
298 | Record the base tree information to identify the state the | |
299 | patch series applies to. See the BASE TREE INFORMATION section | |
300 | below for details. | |
301 | ||
302 | --root:: | |
303 | Treat the revision argument as a <revision range>, even if it | |
304 | is just a single commit (that would normally be treated as a | |
305 | <since>). Note that root commits included in the specified | |
306 | range are always formatted as creation patches, independently | |
307 | of this flag. | |
308 | ||
309 | --progress:: | |
310 | Show progress reports on stderr as patches are generated. | |
311 | ||
312 | CONFIGURATION | |
313 | ------------- | |
314 | You can specify extra mail header lines to be added to each message, | |
315 | defaults for the subject prefix and file suffix, number patches when | |
316 | outputting more than one patch, add "To" or "Cc:" headers, configure | |
317 | attachments, and sign off patches with configuration variables. | |
318 | ||
319 | ------------ | |
320 | [format] | |
321 | headers = "Organization: git-foo\n" | |
322 | subjectPrefix = CHANGE | |
323 | suffix = .txt | |
324 | numbered = auto | |
325 | to = <email> | |
326 | cc = <email> | |
327 | attach [ = mime-boundary-string ] | |
328 | signOff = true | |
329 | coverletter = auto | |
330 | ------------ | |
331 | ||
332 | ||
333 | DISCUSSION | |
334 | ---------- | |
335 | ||
336 | The patch produced by 'git format-patch' is in UNIX mailbox format, | |
337 | with a fixed "magic" time stamp to indicate that the file is output | |
338 | from format-patch rather than a real mailbox, like so: | |
339 | ||
340 | ------------ | |
341 | From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001 | |
342 | From: Tony Luck <tony.luck@intel.com> | |
343 | Date: Tue, 13 Jul 2010 11:42:54 -0700 | |
344 | Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?= | |
345 | =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?= | |
346 | MIME-Version: 1.0 | |
347 | Content-Type: text/plain; charset=UTF-8 | |
348 | Content-Transfer-Encoding: 8bit | |
349 | ||
350 | arch/arm config files were slimmed down using a python script | |
351 | (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment) | |
352 | ||
353 | Do the same for ia64 so we can have sleek & trim looking | |
354 | ... | |
355 | ------------ | |
356 | ||
357 | Typically it will be placed in a MUA's drafts folder, edited to add | |
358 | timely commentary that should not go in the changelog after the three | |
359 | dashes, and then sent as a message whose body, in our example, starts | |
360 | with "arch/arm config files were...". On the receiving end, readers | |
361 | can save interesting patches in a UNIX mailbox and apply them with | |
362 | linkgit:git-am[1]. | |
363 | ||
364 | When a patch is part of an ongoing discussion, the patch generated by | |
365 | 'git format-patch' can be tweaked to take advantage of the 'git am | |
366 | --scissors' feature. After your response to the discussion comes a | |
367 | line that consists solely of "`-- >8 --`" (scissors and perforation), | |
368 | followed by the patch with unnecessary header fields removed: | |
369 | ||
370 | ------------ | |
371 | ... | |
372 | > So we should do such-and-such. | |
373 | ||
374 | Makes sense to me. How about this patch? | |
375 | ||
376 | -- >8 -- | |
377 | Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet | |
378 | ||
379 | arch/arm config files were slimmed down using a python script | |
380 | ... | |
381 | ------------ | |
382 | ||
383 | When sending a patch this way, most often you are sending your own | |
384 | patch, so in addition to the "`From $SHA1 $magic_timestamp`" marker you | |
385 | should omit `From:` and `Date:` lines from the patch file. The patch | |
386 | title is likely to be different from the subject of the discussion the | |
387 | patch is in response to, so it is likely that you would want to keep | |
388 | the Subject: line, like the example above. | |
389 | ||
390 | Checking for patch corruption | |
391 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
392 | Many mailers if not set up properly will corrupt whitespace. Here are | |
393 | two common types of corruption: | |
394 | ||
395 | * Empty context lines that do not have _any_ whitespace. | |
396 | ||
397 | * Non-empty context lines that have one extra whitespace at the | |
398 | beginning. | |
399 | ||
400 | One way to test if your MUA is set up correctly is: | |
401 | ||
402 | * Send the patch to yourself, exactly the way you would, except | |
403 | with To: and Cc: lines that do not contain the list and | |
404 | maintainer address. | |
405 | ||
406 | * Save that patch to a file in UNIX mailbox format. Call it a.patch, | |
407 | say. | |
408 | ||
409 | * Apply it: | |
410 | ||
411 | $ git fetch <project> master:test-apply | |
412 | $ git checkout test-apply | |
413 | $ git reset --hard | |
414 | $ git am a.patch | |
415 | ||
416 | If it does not apply correctly, there can be various reasons. | |
417 | ||
418 | * The patch itself does not apply cleanly. That is _bad_ but | |
419 | does not have much to do with your MUA. You might want to rebase | |
420 | the patch with linkgit:git-rebase[1] before regenerating it in | |
421 | this case. | |
422 | ||
423 | * The MUA corrupted your patch; "am" would complain that | |
424 | the patch does not apply. Look in the .git/rebase-apply/ subdirectory and | |
425 | see what 'patch' file contains and check for the common | |
426 | corruption patterns mentioned above. | |
427 | ||
428 | * While at it, check the 'info' and 'final-commit' files as well. | |
429 | If what is in 'final-commit' is not exactly what you would want to | |
430 | see in the commit log message, it is very likely that the | |
431 | receiver would end up hand editing the log message when applying | |
432 | your patch. Things like "Hi, this is my first patch.\n" in the | |
433 | patch e-mail should come after the three-dash line that signals | |
434 | the end of the commit message. | |
435 | ||
436 | MUA-SPECIFIC HINTS | |
437 | ------------------ | |
438 | Here are some hints on how to successfully submit patches inline using | |
439 | various mailers. | |
440 | ||
441 | GMail | |
442 | ~~~~~ | |
443 | GMail does not have any way to turn off line wrapping in the web | |
444 | interface, so it will mangle any emails that you send. You can however | |
445 | use "git send-email" and send your patches through the GMail SMTP server, or | |
446 | use any IMAP email client to connect to the google IMAP server and forward | |
447 | the emails through that. | |
448 | ||
449 | For hints on using 'git send-email' to send your patches through the | |
450 | GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1]. | |
451 | ||
452 | For hints on submission using the IMAP interface, see the EXAMPLE | |
453 | section of linkgit:git-imap-send[1]. | |
454 | ||
455 | Thunderbird | |
456 | ~~~~~~~~~~~ | |
457 | By default, Thunderbird will both wrap emails as well as flag | |
458 | them as being 'format=flowed', both of which will make the | |
459 | resulting email unusable by Git. | |
460 | ||
461 | There are three different approaches: use an add-on to turn off line wraps, | |
462 | configure Thunderbird to not mangle patches, or use | |
463 | an external editor to keep Thunderbird from mangling the patches. | |
464 | ||
465 | Approach #1 (add-on) | |
466 | ^^^^^^^^^^^^^^^^^^^^ | |
467 | ||
468 | Install the Toggle Word Wrap add-on that is available from | |
469 | https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ | |
470 | It adds a menu entry "Enable Word Wrap" in the composer's "Options" menu | |
471 | that you can tick off. Now you can compose the message as you otherwise do | |
472 | (cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to | |
473 | insert line breaks manually in any text that you type. | |
474 | ||
475 | Approach #2 (configuration) | |
476 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
477 | Three steps: | |
478 | ||
479 | 1. Configure your mail server composition as plain text: | |
480 | Edit...Account Settings...Composition & Addressing, | |
481 | uncheck "Compose Messages in HTML". | |
482 | ||
483 | 2. Configure your general composition window to not wrap. | |
484 | + | |
485 | In Thunderbird 2: | |
486 | Edit..Preferences..Composition, wrap plain text messages at 0 | |
487 | + | |
488 | In Thunderbird 3: | |
489 | Edit..Preferences..Advanced..Config Editor. Search for | |
490 | "mail.wrap_long_lines". | |
491 | Toggle it to make sure it is set to `false`. Also, search for | |
492 | "mailnews.wraplength" and set the value to 0. | |
493 | ||
494 | 3. Disable the use of format=flowed: | |
495 | Edit..Preferences..Advanced..Config Editor. Search for | |
496 | "mailnews.send_plaintext_flowed". | |
497 | Toggle it to make sure it is set to `false`. | |
498 | ||
499 | After that is done, you should be able to compose email as you | |
500 | otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc), | |
501 | and the patches will not be mangled. | |
502 | ||
503 | Approach #3 (external editor) | |
504 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
505 | ||
506 | The following Thunderbird extensions are needed: | |
507 | AboutConfig from http://aboutconfig.mozdev.org/ and | |
508 | External Editor from http://globs.org/articles.php?lng=en&pg=8 | |
509 | ||
510 | 1. Prepare the patch as a text file using your method of choice. | |
511 | ||
512 | 2. Before opening a compose window, use Edit->Account Settings to | |
513 | uncheck the "Compose messages in HTML format" setting in the | |
514 | "Composition & Addressing" panel of the account to be used to | |
515 | send the patch. | |
516 | ||
517 | 3. In the main Thunderbird window, 'before' you open the compose | |
518 | window for the patch, use Tools->about:config to set the | |
519 | following to the indicated values: | |
520 | + | |
521 | ---------- | |
522 | mailnews.send_plaintext_flowed => false | |
523 | mailnews.wraplength => 0 | |
524 | ---------- | |
525 | ||
526 | 4. Open a compose window and click the external editor icon. | |
527 | ||
528 | 5. In the external editor window, read in the patch file and exit | |
529 | the editor normally. | |
530 | ||
531 | Side note: it may be possible to do step 2 with | |
532 | about:config and the following settings but no one's tried yet. | |
533 | ||
534 | ---------- | |
535 | mail.html_compose => false | |
536 | mail.identity.default.compose_html => false | |
537 | mail.identity.id?.compose_html => false | |
538 | ---------- | |
539 | ||
540 | There is a script in contrib/thunderbird-patch-inline which can help | |
541 | you include patches with Thunderbird in an easy way. To use it, do the | |
542 | steps above and then use the script as the external editor. | |
543 | ||
544 | KMail | |
545 | ~~~~~ | |
546 | This should help you to submit patches inline using KMail. | |
547 | ||
548 | 1. Prepare the patch as a text file. | |
549 | ||
550 | 2. Click on New Mail. | |
551 | ||
552 | 3. Go under "Options" in the Composer window and be sure that | |
553 | "Word wrap" is not set. | |
554 | ||
555 | 4. Use Message -> Insert file... and insert the patch. | |
556 | ||
557 | 5. Back in the compose window: add whatever other text you wish to the | |
558 | message, complete the addressing and subject fields, and press send. | |
559 | ||
560 | BASE TREE INFORMATION | |
561 | --------------------- | |
562 | ||
563 | The base tree information block is used for maintainers or third party | |
564 | testers to know the exact state the patch series applies to. It consists | |
565 | of the 'base commit', which is a well-known commit that is part of the | |
566 | stable part of the project history everybody else works off of, and zero | |
567 | or more 'prerequisite patches', which are well-known patches in flight | |
568 | that is not yet part of the 'base commit' that need to be applied on top | |
569 | of 'base commit' in topological order before the patches can be applied. | |
570 | ||
571 | The 'base commit' is shown as "base-commit: " followed by the 40-hex of | |
572 | the commit object name. A 'prerequisite patch' is shown as | |
573 | "prerequisite-patch-id: " followed by the 40-hex 'patch id', which can | |
574 | be obtained by passing the patch through the `git patch-id --stable` | |
575 | command. | |
576 | ||
577 | Imagine that on top of the public commit P, you applied well-known | |
578 | patches X, Y and Z from somebody else, and then built your three-patch | |
579 | series A, B, C, the history would be like: | |
580 | ||
581 | ................................................ | |
582 | ---P---X---Y---Z---A---B---C | |
583 | ................................................ | |
584 | ||
585 | With `git format-patch --base=P -3 C` (or variants thereof, e.g. with | |
586 | `--cover-letter` or using `Z..C` instead of `-3 C` to specify the | |
587 | range), the base tree information block is shown at the end of the | |
588 | first message the command outputs (either the first patch, or the | |
589 | cover letter), like this: | |
590 | ||
591 | ------------ | |
592 | base-commit: P | |
593 | prerequisite-patch-id: X | |
594 | prerequisite-patch-id: Y | |
595 | prerequisite-patch-id: Z | |
596 | ------------ | |
597 | ||
598 | For non-linear topology, such as | |
599 | ||
600 | ................................................ | |
601 | ---P---X---A---M---C | |
602 | \ / | |
603 | Y---Z---B | |
604 | ................................................ | |
605 | ||
606 | You can also use `git format-patch --base=P -3 C` to generate patches | |
607 | for A, B and C, and the identifiers for P, X, Y, Z are appended at the | |
608 | end of the first message. | |
609 | ||
610 | If set `--base=auto` in cmdline, it will track base commit automatically, | |
611 | the base commit will be the merge base of tip commit of the remote-tracking | |
612 | branch and revision-range specified in cmdline. | |
613 | For a local branch, you need to track a remote branch by `git branch | |
614 | --set-upstream-to` before using this option. | |
615 | ||
616 | EXAMPLES | |
617 | -------- | |
618 | ||
619 | * Extract commits between revisions R1 and R2, and apply them on top of | |
620 | the current branch using 'git am' to cherry-pick them: | |
621 | + | |
622 | ------------ | |
623 | $ git format-patch -k --stdout R1..R2 | git am -3 -k | |
624 | ------------ | |
625 | ||
626 | * Extract all commits which are in the current branch but not in the | |
627 | origin branch: | |
628 | + | |
629 | ------------ | |
630 | $ git format-patch origin | |
631 | ------------ | |
632 | + | |
633 | For each commit a separate file is created in the current directory. | |
634 | ||
635 | * Extract all commits that lead to 'origin' since the inception of the | |
636 | project: | |
637 | + | |
638 | ------------ | |
639 | $ git format-patch --root origin | |
640 | ------------ | |
641 | ||
642 | * The same as the previous one: | |
643 | + | |
644 | ------------ | |
645 | $ git format-patch -M -B origin | |
646 | ------------ | |
647 | + | |
648 | Additionally, it detects and handles renames and complete rewrites | |
649 | intelligently to produce a renaming patch. A renaming patch reduces | |
650 | the amount of text output, and generally makes it easier to review. | |
651 | Note that non-Git "patch" programs won't understand renaming patches, so | |
652 | use it only when you know the recipient uses Git to apply your patch. | |
653 | ||
654 | * Extract three topmost commits from the current branch and format them | |
655 | as e-mailable patches: | |
656 | + | |
657 | ------------ | |
658 | $ git format-patch -3 | |
659 | ------------ | |
660 | ||
661 | SEE ALSO | |
662 | -------- | |
663 | linkgit:git-am[1], linkgit:git-send-email[1] | |
664 | ||
665 | GIT | |
666 | --- | |
667 | Part of the linkgit:git[1] suite |