1GIT-FORMAT-PATCH(1) Git Manual GIT-FORMAT-PATCH(1)
2
6 git-format-patch - Prepare patches for e-mail submission
7
9 git format-patch [-k] [(-o|--output-directory) <dir> | --stdout]
10 [--no-thread | --thread[=<style>]]
11 [(--attach|--inline)[=<boundary>] | --no-attach]
12 [-s | --signoff]
13 [--signature=<signature> | --no-signature]
14 [-n | --numbered | -N | --no-numbered]
15 [--start-number <n>] [--numbered-files]
16 [--in-reply-to=Message-Id] [--suffix=.<sfx>]
17 [--ignore-if-in-upstream]
18 [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
19 [--to=<email>] [--cc=<email>]
20 [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
21 [<common diff options>]
22 [ <since> | <revision range> ]
23
26 Prepare each commit with its patch in one file per commit, formatted to
27 resemble UNIX mailbox format. The output of this command is convenient
28 for e-mail submission or for use with git am.
29 There are two ways to specify which commits to operate on.
31 1. A single commit, <since>, specifies that the commits leading to the
33 tip of the current branch that are not in the history that leads to
34 the <since> to be output.
35 2. Generic <revision range> expression (see "SPECIFYING REVISIONS"
37 section in gitrevisions(7)) means the commits in the specified
38 range.
39 The first rule takes precedence in the case of a single <commit>. To
41 apply the second rule, i.e., format everything since the beginning of
42 history up until <commit>, use the --root option: git format-patch
43 --root <commit>. If you want to format only <commit> itself, you can do
44 this with git format-patch -1 <commit>.
45 By default, each output file is numbered sequentially from 1, and uses
47 the first line of the commit message (massaged for pathname safety) as
48 the filename. With the --numbered-files option, the output file names
49 will only be numbers, without the first line of the commit appended.
50 The names of the output files are printed to standard output, unless
51 the --stdout option is specified.
52 If -o is specified, output files are created in <dir>. Otherwise they
54 are created in the current working directory.
55 By default, the subject of a single patch is "[PATCH] " followed by the
57 concatenation of lines from the commit message up to the first blank
58 line (see the DISCUSSION section of git-commit(1)).
59 When multiple patches are output, the subject prefix will instead be
61 "[PATCH n/m] ". To force 1/1 to be added for a single patch, use -n. To
62 omit patch numbers from the subject, use -N.
63 If given --thread, git-format-patch will generate In-Reply-To and
65 References headers to make the second and subsequent patch mails appear
66 as replies to the first mail; this also generates a Message-Id header
67 to reference.
68
70 -p, --no-stat
71 Generate plain patches without any diffstats.
72 -U<n>, --unified=<n>
74 Generate diffs with <n> lines of context instead of the usual
75 three.
76 --minimal
78 Spend extra time to make sure the smallest possible diff is
79 produced.
80 --patience
82 Generate a diff using the "patience diff" algorithm.
83 --histogram
85 Generate a diff using the "histogram diff" algorithm.
86 --diff-algorithm={patience|minimal|histogram|myers}
88 Choose a diff algorithm. The variants are as follows:
89 default, myers
91 The basic greedy diff algorithm. Currently, this is the
92 default.
93 minimal
95 Spend extra time to make sure the smallest possible diff is
96 produced.
97 patience
99 Use "patience diff" algorithm when generating patches.
100 histogram
102 This algorithm extends the patience algorithm to "support
103 low-occurrence common elements".
104 For instance, if you configured diff.algorithm variable to a
106 non-default value and want to use the default one, then you have to
107 use --diff-algorithm=default option.
108 --stat[=<width>[,<name-width>[,<count>]]]
110 Generate a diffstat. By default, as much space as necessary will be
111 used for the filename part, and the rest for the graph part.
112 Maximum width defaults to terminal width, or 80 columns if not
113 connected to a terminal, and can be overridden by <width>. The
114 width of the filename part can be limited by giving another width
115 <name-width> after a comma. The width of the graph part can be
116 limited by using --stat-graph-width=<width> (affects all commands
117 generating a stat graph) or by setting diff.statGraphWidth=<width>
118 (does not affect git format-patch). By giving a third parameter
119 <count>, you can limit the output to the first <count> lines,
120 followed by ... if there are more.
121 These parameters can also be set individually with
123 --stat-width=<width>, --stat-name-width=<name-width> and
124 --stat-count=<count>.
125 --numstat
127 Similar to --stat, but shows number of added and deleted lines in
128 decimal notation and pathname without abbreviation, to make it more
129 machine friendly. For binary files, outputs two - instead of saying
130 0 0.
131 --shortstat
133 Output only the last line of the --stat format containing total
134 number of modified files, as well as number of added and deleted
135 lines.
136 --dirstat[=<param1,param2,...>]
138 Output the distribution of relative amount of changes for each
139 sub-directory. The behavior of --dirstat can be customized by
140 passing it a comma separated list of parameters. The defaults are
141 controlled by the diff.dirstat configuration variable (see git-
142 config(1)). The following parameters are available:
143 changes
145 Compute the dirstat numbers by counting the lines that have
146 been removed from the source, or added to the destination. This
147 ignores the amount of pure code movements within a file. In
148 other words, rearranging lines in a file is not counted as much
149 as other changes. This is the default behavior when no
150 parameter is given.
151 lines
153 Compute the dirstat numbers by doing the regular line-based
154 diff analysis, and summing the removed/added line counts. (For
155 binary files, count 64-byte chunks instead, since binary files
156 have no natural concept of lines). This is a more expensive
157 --dirstat behavior than the changes behavior, but it does count
158 rearranged lines within a file as much as other changes. The
159 resulting output is consistent with what you get from the other
160 --*stat options.
161 files
163 Compute the dirstat numbers by counting the number of files
164 changed. Each changed file counts equally in the dirstat
165 analysis. This is the computationally cheapest --dirstat
166 behavior, since it does not have to look at the file contents
167 at all.
168 cumulative
170 Count changes in a child directory for the parent directory as
171 well. Note that when using cumulative, the sum of the
172 percentages reported may exceed 100%. The default
173 (non-cumulative) behavior can be specified with the
174 noncumulative parameter.
175 <limit>
177 An integer parameter specifies a cut-off percent (3% by
178 default). Directories contributing less than this percentage of
179 the changes are not shown in the output.
180 Example: The following will count changed files, while ignoring
182 directories with less than 10% of the total amount of changed
183 files, and accumulating child directory counts in the parent
184 directories: --dirstat=files,10,cumulative.
185 --summary
187 Output a condensed summary of extended header information such as
188 creations, renames and mode changes.
189 --no-renames
191 Turn off rename detection, even when the configuration file gives
192 the default to do so.
193 --full-index
195 Instead of the first handful of characters, show the full pre- and
196 post-image blob object names on the "index" line when generating
197 patch format output.
198 --binary
200 In addition to --full-index, output a binary diff that can be
201 applied with git-apply.
202 --abbrev[=<n>]
204 Instead of showing the full 40-byte hexadecimal object name in
205 diff-raw format output and diff-tree header lines, show only a
206 partial prefix. This is independent of the --full-index option
207 above, which controls the diff-patch output format. Non default
208 number of digits can be specified with --abbrev=<n>.
209 -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]]
211 Break complete rewrite changes into pairs of delete and create.
212 This serves two purposes:
213 It affects the way a change that amounts to a total rewrite of a
215 file not as a series of deletion and insertion mixed together with
216 a very few lines that happen to match textually as the context, but
217 as a single deletion of everything old followed by a single
218 insertion of everything new, and the number m controls this aspect
219 of the -B option (defaults to 60%). -B/70% specifies that less
220 than 30% of the original should remain in the result for Git to
221 consider it a total rewrite (i.e. otherwise the resulting patch
222 will be a series of deletion and insertion mixed together with
223 context lines).
224 When used with -M, a totally-rewritten file is also considered as
226 the source of a rename (usually -M only considers a file that
227 disappeared as the source of a rename), and the number n controls
228 this aspect of the -B option (defaults to 50%). -B20% specifies
229 that a change with addition and deletion compared to 20% or more of
230 the file’s size are eligible for being picked up as a possible
231 source of a rename to another file.
232 -M[<n>], --find-renames[=<n>]
234 Detect renames. If n is specified, it is a threshold on the
235 similarity index (i.e. amount of addition/deletions compared to the
236 file’s size). For example, -M90% means Git should consider a
237 delete/add pair to be a rename if more than 90% of the file hasn’t
238 changed. Without a % sign, the number is to be read as a fraction,
239 with a decimal point before it. I.e., -M5 becomes 0.5, and is thus
240 the same as -M50%. Similarly, -M05 is the same as -M5%. To limit
241 detection to exact renames, use -M100%.
242 -C[<n>], --find-copies[=<n>]
244 Detect copies as well as renames. See also --find-copies-harder. If
245 n is specified, it has the same meaning as for -M<n>.
246 --find-copies-harder
248 For performance reasons, by default, -C option finds copies only if
249 the original file of the copy was modified in the same changeset.
250 This flag makes the command inspect unmodified files as candidates
251 for the source of copy. This is a very expensive operation for
252 large projects, so use it with caution. Giving more than one -C
253 option has the same effect.
254 -D, --irreversible-delete
256 Omit the preimage for deletes, i.e. print only the header but not
257 the diff between the preimage and /dev/null. The resulting patch is
258 not meant to be applied with patch nor git apply; this is solely
259 for people who want to just concentrate on reviewing the text after
260 the change. In addition, the output obviously lack enough
261 information to apply such a patch in reverse, even manually, hence
262 the name of the option.
263 When used together with -B, omit also the preimage in the deletion
265 part of a delete/create pair.
266 -l<num>
268 The -M and -C options require O(n^2) processing time where n is the
269 number of potential rename/copy targets. This option prevents
270 rename/copy detection from running if the number of rename/copy
271 targets exceeds the specified number.
272 -O<orderfile>
274 Output the patch in the order specified in the <orderfile>, which
275 has one shell glob pattern per line.
276 -a, --text
278 Treat all files as text.
279 --ignore-space-at-eol
281 Ignore changes in whitespace at EOL.
282 -b, --ignore-space-change
284 Ignore changes in amount of whitespace. This ignores whitespace at
285 line end, and considers all other sequences of one or more
286 whitespace characters to be equivalent.
287 -w, --ignore-all-space
289 Ignore whitespace when comparing lines. This ignores differences
290 even if one line has whitespace where the other line has none.
291 --inter-hunk-context=<lines>
293 Show the context between diff hunks, up to the specified number of
294 lines, thereby fusing hunks that are close to each other.
295 -W, --function-context
297 Show whole surrounding functions of changes.
298 --ext-diff
300 Allow an external diff helper to be executed. If you set an
301 external diff driver with gitattributes(5), you need to use this
302 option with git-log(1) and friends.
303 --no-ext-diff
305 Disallow external diff drivers.
306 --textconv, --no-textconv
308 Allow (or disallow) external text conversion filters to be run when
309 comparing binary files. See gitattributes(5) for details. Because
310 textconv filters are typically a one-way conversion, the resulting
311 diff is suitable for human consumption, but cannot be applied. For
312 this reason, textconv filters are enabled by default only for git-
313 diff(1) and git-log(1), but not for git-format-patch(1) or diff
314 plumbing commands.
315 --ignore-submodules[=<when>]
317 Ignore changes to submodules in the diff generation. <when> can be
318 either "none", "untracked", "dirty" or "all", which is the default.
319 Using "none" will consider the submodule modified when it either
320 contains untracked or modified files or its HEAD differs from the
321 commit recorded in the superproject and can be used to override any
322 settings of the ignore option in git-config(1) or gitmodules(5).
323 When "untracked" is used submodules are not considered dirty when
324 they only contain untracked content (but they are still scanned for
325 modified content). Using "dirty" ignores all changes to the work
326 tree of submodules, only changes to the commits stored in the
327 superproject are shown (this was the behavior until 1.7.0). Using
328 "all" hides all changes to submodules.
329 --src-prefix=<prefix>
331 Show the given source prefix instead of "a/".
332 --dst-prefix=<prefix>
334 Show the given destination prefix instead of "b/".
335 --no-prefix
337 Do not show any source or destination prefix.
338 For more detailed explanation on these common options, see also
340 gitdiffcore(7).
341 -<n>
343 Prepare patches from the topmost <n> commits.
344 -o <dir>, --output-directory <dir>
346 Use <dir> to store the resulting files, instead of the current
347 working directory.
348 -n, --numbered
350 Name output in [PATCH n/m] format, even with a single patch.
351 -N, --no-numbered
353 Name output in [PATCH] format.
354 --start-number <n>
356 Start numbering the patches at <n> instead of 1.
357 --numbered-files
359 Output file names will be a simple number sequence without the
360 default first line of the commit appended.
361 -k, --keep-subject
363 Do not strip/add [PATCH] from the first line of the commit log
364 message.
365 -s, --signoff
367 Add Signed-off-by: line to the commit message, using the committer
368 identity of yourself.
369 --stdout
371 Print all commits to the standard output in mbox format, instead of
372 creating a file for each one.
373 --attach[=<boundary>]
375 Create multipart/mixed attachment, the first part of which is the
376 commit message and the patch itself in the second part, with
377 Content-Disposition: attachment.
378 --no-attach
380 Disable the creation of an attachment, overriding the configuration
381 setting.
382 --inline[=<boundary>]
384 Create multipart/mixed attachment, the first part of which is the
385 commit message and the patch itself in the second part, with
386 Content-Disposition: inline.
387 --thread[=<style>], --no-thread
389 Controls addition of In-Reply-To and References headers to make the
390 second and subsequent mails appear as replies to the first. Also
391 controls generation of the Message-Id header to reference.
392 The optional <style> argument can be either shallow or deep.
394 shallow threading makes every mail a reply to the head of the
395 series, where the head is chosen from the cover letter, the
396 --in-reply-to, and the first patch mail, in this order. deep
397 threading makes every mail a reply to the previous one.
398 The default is --no-thread, unless the format.thread configuration
400 is set. If --thread is specified without a style, it defaults to
401 the style specified by format.thread if any, or else shallow.
402 Beware that the default for git send-email is to thread emails
404 itself. If you want git format-patch to take care of threading, you
405 will want to ensure that threading is disabled for git send-email.
406 --in-reply-to=Message-Id
408 Make the first mail (or all the mails with --no-thread) appear as a
409 reply to the given Message-Id, which avoids breaking threads to
410 provide a new patch series.
411 --ignore-if-in-upstream
413 Do not include a patch that matches a commit in <until>..<since>.
414 This will examine all patches reachable from <since> but not from
415 <until> and compare them with the patches being generated, and any
416 patch that matches is ignored.
417 --subject-prefix=<Subject-Prefix>
419 Instead of the standard [PATCH] prefix in the subject line, instead
420 use [<Subject-Prefix>]. This allows for useful naming of a patch
421 series, and can be combined with the --numbered option.
422 -v <n>, --reroll-count=<n>
424 Mark the series as the <n>-th iteration of the topic. The output
425 filenames have v<n> pretended to them, and the subject prefix
426 ("PATCH" by default, but configurable via the --subject-prefix
427 option) has ` v<n>` appended to it. E.g. --reroll-count=4 may
428 produce v4-0001-add-makefile.patch file that has "Subject: [PATCH
429 v4 1/20] Add makefile" in it.
430 --to=<email>
432 Add a To: header to the email headers. This is in addition to any
433 configured headers, and may be used multiple times. The negated
434 form --no-to discards all To: headers added so far (from config or
435 command line).
436 --cc=<email>
438 Add a Cc: header to the email headers. This is in addition to any
439 configured headers, and may be used multiple times. The negated
440 form --no-cc discards all Cc: headers added so far (from config or
441 command line).
442 --add-header=<header>
444 Add an arbitrary header to the email headers. This is in addition
445 to any configured headers, and may be used multiple times. For
446 example, --add-header="Organization: git-foo". The negated form
447 --no-add-header discards all (To:, Cc:, and custom) headers added
448 so far from config or command line.
449 --[no-]cover-letter
451 In addition to the patches, generate a cover letter file containing
452 the shortlog and the overall diffstat. You can fill in a
453 description in the file before sending it out.
454 --notes[=<ref>]
456 Append the notes (see git-notes(1)) for the commit after the
457 three-dash line.
458 The expected use case of this is to write supporting explanation
460 for the commit that does not belong to the commit log message
461 proper, and include it with the patch submission. While one can
462 simply write these explanations after format-patch has run but
463 before sending, keeping them as Git notes allows them to be
464 maintained between versions of the patch series (but see the
465 discussion of the notes.rewrite configuration options in git-
466 notes(1) to use this workflow).
467 --[no]-signature=<signature>
469 Add a signature to each message produced. Per RFC 3676 the
470 signature is separated from the body by a line with '-- ' on it. If
471 the signature option is omitted the signature defaults to the Git
472 version number.
473 --suffix=.<sfx>
475 Instead of using .patch as the suffix for generated filenames, use
476 specified suffix. A common alternative is --suffix=.txt. Leaving
477 this empty will remove the .patch suffix.
478 Note that the leading character does not have to be a dot; for
480 example, you can use --suffix=-patch to get
481 0001-description-of-my-change-patch.
482 --quiet
484 Do not print the names of the generated files to standard output.
485 --no-binary
487 Do not output contents of changes in binary files, instead display
488 a notice that those files changed. Patches generated using this
489 option cannot be applied properly, but they are still useful for
490 code review.
491 --root
493 Treat the revision argument as a <revision range>, even if it is
494 just a single commit (that would normally be treated as a <since>).
495 Note that root commits included in the specified range are always
496 formatted as creation patches, independently of this flag.
497
499 You can specify extra mail header lines to be added to each message,
500 defaults for the subject prefix and file suffix, number patches when
501 outputting more than one patch, add "To" or "Cc:" headers, configure
502 attachments, and sign off patches with configuration variables.
503 [format]
505 headers = "Organization: git-foo\n"
506 subjectprefix = CHANGE
507 suffix = .txt
508 numbered = auto
509 to = <email>
510 cc = <email>
511 attach [ = mime-boundary-string ]
512 signoff = true
513 coverletter = auto
514
517 The patch produced by git format-patch is in UNIX mailbox format, with
518 a fixed "magic" time stamp to indicate that the file is output from
519 format-patch rather than a real mailbox, like so:
520 From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001
522 From: Tony Luck <tony.luck@intel.com>
523 Date: Tue, 13 Jul 2010 11:42:54 -0700
524 Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=
525 =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=
526 MIME-Version: 1.0
527 Content-Type: text/plain; charset=UTF-8
528 Content-Transfer-Encoding: 8bit
529 arch/arm config files were slimmed down using a python script
531 (See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)
532 Do the same for ia64 so we can have sleek & trim looking
534 ...
535 Typically it will be placed in a MUA’s drafts folder, edited to add
538 timely commentary that should not go in the changelog after the three
539 dashes, and then sent as a message whose body, in our example, starts
540 with "arch/arm config files were...". On the receiving end, readers can
541 save interesting patches in a UNIX mailbox and apply them with git-
542 am(1).
543 When a patch is part of an ongoing discussion, the patch generated by
545 git format-patch can be tweaked to take advantage of the git am
546 --scissors feature. After your response to the discussion comes a line
547 that consists solely of "-- >8 --" (scissors and perforation), followed
548 by the patch with unnecessary header fields removed:
549 ...
551 > So we should do such-and-such.
552 Makes sense to me. How about this patch?
554 -- >8 --
556 Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet
557 arch/arm config files were slimmed down using a python script
559 ...
560 When sending a patch this way, most often you are sending your own
563 patch, so in addition to the "From $SHA1 $magic_timestamp" marker you
564 should omit From: and Date: lines from the patch file. The patch title
565 is likely to be different from the subject of the discussion the patch
566 is in response to, so it is likely that you would want to keep the
567 Subject: line, like the example above.
568 Checking for patch corruption
570 Many mailers if not set up properly will corrupt whitespace. Here are
571 two common types of corruption:
572 · Empty context lines that do not have any whitespace.
574 · Non-empty context lines that have one extra whitespace at the
576 beginning.
577 One way to test if your MUA is set up correctly is:
579 · Send the patch to yourself, exactly the way you would, except with
581 To: and Cc: lines that do not contain the list and maintainer
582 address.
583 · Save that patch to a file in UNIX mailbox format. Call it a.patch,
585 say.
586 · Apply it:
588 $ git fetch <project> master:test-apply
590 $ git checkout test-apply
591 $ git reset --hard
592 $ git am a.patch
593 If it does not apply correctly, there can be various reasons.
595 · The patch itself does not apply cleanly. That is bad but does not
597 have much to do with your MUA. You might want to rebase the patch
598 with git-rebase(1) before regenerating it in this case.
599 · The MUA corrupted your patch; "am" would complain that the patch
601 does not apply. Look in the .git/rebase-apply/ subdirectory and see
602 what patch file contains and check for the common corruption
603 patterns mentioned above.
604 · While at it, check the info and final-commit files as well. If what
606 is in final-commit is not exactly what you would want to see in the
607 commit log message, it is very likely that the receiver would end
608 up hand editing the log message when applying your patch. Things
609 like "Hi, this is my first patch.\n" in the patch e-mail should
610 come after the three-dash line that signals the end of the commit
611 message.
612
614 Here are some hints on how to successfully submit patches inline using
615 various mailers.
616 GMail
618 GMail does not have any way to turn off line wrapping in the web
619 interface, so it will mangle any emails that you send. You can however
620 use "git send-email" and send your patches through the GMail SMTP
621 server, or use any IMAP email client to connect to the google IMAP
622 server and forward the emails through that.
623 For hints on using git send-email to send your patches through the
625 GMail SMTP server, see the EXAMPLE section of git-send-email(1).
626 For hints on submission using the IMAP interface, see the EXAMPLE
628 section of git-imap-send(1).
629 Thunderbird
631 By default, Thunderbird will both wrap emails as well as flag them as
632 being format=flowed, both of which will make the resulting email
633 unusable by Git.
634 There are three different approaches: use an add-on to turn off line
636 wraps, configure Thunderbird to not mangle patches, or use an external
637 editor to keep Thunderbird from mangling the patches.
638 Approach #1 (add-on)
640 Install the Toggle Word Wrap add-on that is available from
641 https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/ It
642 adds a menu entry "Enable Word Wrap" in the composer’s "Options"
643 menu that you can tick off. Now you can compose the message as you
644 otherwise do (cut + paste, git format-patch | git imap-send, etc),
645 but you have to insert line breaks manually in any text that you
646 type.
647 Approach #2 (configuration)
649 Three steps:
650 1. Configure your mail server composition as plain text:
652 Edit...Account Settings...Composition & Addressing, uncheck
653 "Compose Messages in HTML".
654 2. Configure your general composition window to not wrap.
656 In Thunderbird 2: Edit..Preferences..Composition, wrap plain
658 text messages at 0
659 In Thunderbird 3: Edit..Preferences..Advanced..Config Editor.
661 Search for "mail.wrap_long_lines". Toggle it to make sure it is
662 set to false.
663 3. Disable the use of format=flowed:
665 Edit..Preferences..Advanced..Config Editor. Search for
666 "mailnews.send_plaintext_flowed". Toggle it to make sure it is
667 set to false.
668 After that is done, you should be able to compose email as you
670 otherwise would (cut + paste, git format-patch | git imap-send,
671 etc), and the patches will not be mangled.
672 Approach #3 (external editor)
674 The following Thunderbird extensions are needed: AboutConfig from
675 http://aboutconfig.mozdev.org/ and External Editor from
676 http://globs.org/articles.php?lng=en&pg=8
677 1. Prepare the patch as a text file using your method of choice.
679 2. Before opening a compose window, use Edit→Account Settings to
681 uncheck the "Compose messages in HTML format" setting in the
682 "Composition & Addressing" panel of the account to be used to
683 send the patch.
684 3. In the main Thunderbird window, before you open the compose
686 window for the patch, use Tools→about:config to set the
687 following to the indicated values:
688 mailnews.send_plaintext_flowed => false
690 mailnews.wraplength => 0
691 4. Open a compose window and click the external editor icon.
694 5. In the external editor window, read in the patch file and exit
696 the editor normally.
697 Side note: it may be possible to do step 2 with about:config and
699 the following settings but no one’s tried yet.
700 mail.html_compose => false
702 mail.identity.default.compose_html => false
703 mail.identity.id?.compose_html => false
704 There is a script in contrib/thunderbird-patch-inline which can
707 help you include patches with Thunderbird in an easy way. To use
708 it, do the steps above and then use the script as the external
709 editor.
710 KMail
712 This should help you to submit patches inline using KMail.
713 1. Prepare the patch as a text file.
715 2. Click on New Mail.
717 3. Go under "Options" in the Composer window and be sure that "Word
719 wrap" is not set.
720 4. Use Message → Insert file... and insert the patch.
722 5. Back in the compose window: add whatever other text you wish to the
724 message, complete the addressing and subject fields, and press
725 send.
726
728 · Extract commits between revisions R1 and R2, and apply them on top
729 of the current branch using git am to cherry-pick them:
730 $ git format-patch -k --stdout R1..R2 | git am -3 -k
732 · Extract all commits which are in the current branch but not in the
735 origin branch:
736 $ git format-patch origin
738 For each commit a separate file is created in the current
740 directory.
741 · Extract all commits that lead to origin since the inception of the
743 project:
744 $ git format-patch --root origin
746 · The same as the previous one:
749 $ git format-patch -M -B origin
751 Additionally, it detects and handles renames and complete rewrites
753 intelligently to produce a renaming patch. A renaming patch reduces
754 the amount of text output, and generally makes it easier to review.
755 Note that non-Git "patch" programs won’t understand renaming
756 patches, so use it only when you know the recipient uses Git to
757 apply your patch.
758 · Extract three topmost commits from the current branch and format
760 them as e-mailable patches:
761 $ git format-patch -3
763
766 git-am(1), git-send-email(1)
767
769 Part of the git(1) suite
770Git 1.8.3.1 11/19/2018 GIT-FORMAT-PATCH(1)