]>
Commit | Line | Data |
---|---|---|
56333bac JS |
1 | Checklist (and a short version for the impatient): |
2 | ||
a7af09d2 JA |
3 | Commits: |
4 | ||
56333bac JS |
5 | - make commits of logical units |
6 | - check for unnecessary whitespace with "git diff --check" | |
7 | before committing | |
8 | - do not check in commented out code or unneeded files | |
56333bac | 9 | - the first line of the commit message should be a short |
43e331e6 ÆAB |
10 | description (50 characters is the soft limit, see DISCUSSION |
11 | in git-commit(1)), and should skip the full stop | |
47afed5d | 12 | - the body should provide a meaningful commit message, which: |
d0f7dcbf JH |
13 | . explains the problem the change tries to solve, iow, what |
14 | is wrong with the current code without the change. | |
15 | . justifies the way the change solves the problem, iow, why | |
16 | the result with the change is better. | |
17 | . alternate solutions considered but discarded, if any. | |
18 | - describe changes in imperative mood, e.g. "make xyzzy do frotz" | |
19 | instead of "[This patch] makes xyzzy do frotz" or "[I] changed | |
20 | xyzzy to do frotz", as if you are giving orders to the codebase | |
21 | to change its behaviour. | |
22 | - try to make sure your explanation can be understood without | |
23 | external resources. Instead of giving a URL to a mailing list | |
24 | archive, summarize the relevant points of the discussion. | |
6a58696f ÆAB |
25 | - add a "Signed-off-by: Your Name <you@example.com>" line to the |
26 | commit message (or just use the option "-s" when committing) | |
27 | to confirm that you agree to the Developer's Certificate of Origin | |
d3017e93 JS |
28 | - make sure that you have tests for the bug you are fixing |
29 | - make sure that the test suite passes after your commit | |
a7af09d2 JA |
30 | |
31 | Patch: | |
32 | ||
56333bac | 33 | - use "git format-patch -M" to create the patch |
a7af09d2 | 34 | - do not PGP sign your patch |
56333bac JS |
35 | - do not attach your patch, but read in the mail |
36 | body, unless you cannot teach your mailer to | |
37 | leave the formatting of the patch alone. | |
38 | - be careful doing cut & paste into your mailer, not to | |
39 | corrupt whitespaces. | |
40 | - provide additional information (which is unsuitable for | |
41 | the commit message) between the "---" and the diffstat | |
15320175 AR |
42 | - if you change, add, or remove a command line option or |
43 | make some other user interface change, the associated | |
44 | documentation should be updated as well. | |
d3017e93 JS |
45 | - if your name is not writable in ASCII, make sure that |
46 | you send off a message in the correct encoding. | |
13d4e6f7 | 47 | - send the patch to the list (git@vger.kernel.org) and the |
0b059940 JH |
48 | maintainer (gitster@pobox.com) if (and only if) the patch |
49 | is ready for inclusion. If you use git-send-email(1), | |
50 | please test it first by sending email to yourself. | |
e498257d | 51 | - see below for instructions specific to your mailer |
56333bac JS |
52 | |
53 | Long version: | |
54 | ||
31408251 JH |
55 | I started reading over the SubmittingPatches document for Linux |
56 | kernel, primarily because I wanted to have a document similar to | |
57 | it for the core GIT to make sure people understand what they are | |
58 | doing when they write "Signed-off-by" line. | |
59 | ||
60 | But the patch submission requirements are a lot more relaxed | |
45d2b286 JH |
61 | here on the technical/contents front, because the core GIT is |
62 | thousand times smaller ;-). So here is only the relevant bits. | |
31408251 | 63 | |
d0c26f0f RR |
64 | (0) Decide what to base your work on. |
65 | ||
66 | In general, always base your work on the oldest branch that your | |
67 | change is relevant to. | |
68 | ||
69 | - A bugfix should be based on 'maint' in general. If the bug is not | |
70 | present in 'maint', base it on 'master'. For a bug that's not yet | |
71 | in 'master', find the topic that introduces the regression, and | |
72 | base your work on the tip of the topic. | |
73 | ||
74 | - A new feature should be based on 'master' in general. If the new | |
75 | feature depends on a topic that is in 'pu', but not in 'master', | |
76 | base your work on the tip of that topic. | |
77 | ||
78 | - Corrections and enhancements to a topic not yet in 'master' should | |
79 | be based on the tip of that topic. If the topic has not been merged | |
80 | to 'next', it's alright to add a note to squash minor corrections | |
81 | into the series. | |
82 | ||
83 | - In the exceptional case that a new feature depends on several topics | |
84 | not in 'master', start working on 'next' or 'pu' privately and send | |
85 | out patches for discussion. Before the final merge, you may have to | |
86 | wait until some of the dependent topics graduate to 'master', and | |
87 | rebase your work. | |
88 | ||
89 | To find the tip of a topic branch, run "git log --first-parent | |
90 | master..pu" and look for the merge commit. The second parent of this | |
91 | commit is the tip of the topic branch. | |
31408251 JH |
92 | |
93 | (1) Make separate commits for logically separate changes. | |
94 | ||
95 | Unless your patch is really trivial, you should not be sending | |
96 | out a patch that was generated between your working tree and | |
97 | your commit head. Instead, always make a commit with complete | |
98 | commit message and generate a series of patches from your | |
99 | repository. It is a good discipline. | |
100 | ||
d0f7dcbf JH |
101 | Give an explanation for the change(s) that is detailed enough so |
102 | that people can judge if it is good thing to do, without reading | |
103 | the actual patch text to determine how well the code does what | |
104 | the explanation promises to do. | |
31408251 | 105 | |
45d2b286 | 106 | If your description starts to get too long, that's a sign that you |
31408251 | 107 | probably need to split up your commit to finer grained pieces. |
47afed5d SV |
108 | That being said, patches which plainly describe the things that |
109 | help reviewers check the patch, and future maintainers understand | |
110 | the code, are the most beautiful patches. Descriptions that summarise | |
111 | the point in the subject well, and describe the motivation for the | |
112 | change, the approach taken by the change, and if relevant how this | |
d0f7dcbf JH |
113 | differs substantially from the prior version, are all good things |
114 | to have. | |
31408251 | 115 | |
45d2b286 JH |
116 | Oh, another thing. I am picky about whitespaces. Make sure your |
117 | changes do not trigger errors with the sample pre-commit hook shipped | |
16507fcf BL |
118 | in templates/hooks--pre-commit. To help ensure this does not happen, |
119 | run git diff --check on your changes before you commit. | |
31408251 | 120 | |
31408251 | 121 | |
243bfd33 JS |
122 | (1a) Try to be nice to older C compilers |
123 | ||
8b1d88e8 | 124 | We try to support a wide range of C compilers to compile |
243bfd33 JS |
125 | git with. That means that you should not use C99 initializers, even |
126 | if a lot of compilers grok it. | |
127 | ||
128 | Also, variables have to be declared at the beginning of the block | |
129 | (you can check this with gcc, using the -Wdeclaration-after-statement | |
130 | option). | |
131 | ||
132 | Another thing: NULL pointers shall be written as NULL, not as 0. | |
133 | ||
134 | ||
45d2b286 JH |
135 | (2) Generate your patch using git tools out of your commits. |
136 | ||
137 | git based diff tools (git, Cogito, and StGIT included) generate | |
138 | unidiff which is the preferred format. | |
139 | ||
31408251 JH |
140 | You do not have to be afraid to use -M option to "git diff" or |
141 | "git format-patch", if your patch involves file renames. The | |
142 | receiving end can handle them just fine. | |
143 | ||
144 | Please make sure your patch does not include any extra files | |
145 | which do not belong in a patch submission. Make sure to review | |
146 | your patch after generating it, to ensure accuracy. Before | |
147 | sending out, please make sure it cleanly applies to the "master" | |
45d2b286 JH |
148 | branch head. If you are preparing a work based on "next" branch, |
149 | that is fine, but please mark it as such. | |
31408251 JH |
150 | |
151 | ||
152 | (3) Sending your patches. | |
153 | ||
45d2b286 | 154 | People on the git mailing list need to be able to read and |
31408251 JH |
155 | comment on the changes you are submitting. It is important for |
156 | a developer to be able to "quote" your changes, using standard | |
157 | e-mail tools, so that they may comment on specific portions of | |
addf88e4 | 158 | your code. For this reason, all patches should be submitted |
45d2b286 JH |
159 | "inline". WARNING: Be wary of your MUAs word-wrap |
160 | corrupting your patch. Do not cut-n-paste your patch; you can | |
161 | lose tabs that way if you are not careful. | |
31408251 | 162 | |
45d2b286 | 163 | It is a common convention to prefix your subject line with |
31408251 | 164 | [PATCH]. This lets people easily distinguish patches from other |
4e891acf JH |
165 | e-mail discussions. Use of additional markers after PATCH and |
166 | the closing bracket to mark the nature of the patch is also | |
167 | encouraged. E.g. [PATCH/RFC] is often used when the patch is | |
168 | not ready to be applied but it is for discussion, [PATCH v2], | |
169 | [PATCH v3] etc. are often seen when you are sending an update to | |
170 | what you have previously sent. | |
31408251 JH |
171 | |
172 | "git format-patch" command follows the best current practice to | |
173 | format the body of an e-mail message. At the beginning of the | |
174 | patch should come your commit message, ending with the | |
175 | Signed-off-by: lines, and a line that consists of three dashes, | |
176 | followed by the diffstat information and the patch itself. If | |
177 | you are forwarding a patch from somebody else, optionally, at | |
178 | the beginning of the e-mail message just before the commit | |
179 | message starts, you can put a "From: " line to name that person. | |
180 | ||
181 | You often want to add additional explanation about the patch, | |
182 | other than the commit message itself. Place such "cover letter" | |
183 | material between the three dash lines and the diffstat. | |
184 | ||
185 | Do not attach the patch as a MIME attachment, compressed or not. | |
e30b217b JH |
186 | Do not let your e-mail client send quoted-printable. Do not let |
187 | your e-mail client send format=flowed which would destroy | |
188 | whitespaces in your patches. Many | |
31408251 JH |
189 | popular e-mail applications will not always transmit a MIME |
190 | attachment as plain text, making it impossible to comment on | |
191 | your code. A MIME attachment also takes a bit more time to | |
192 | process. This does not decrease the likelihood of your | |
193 | MIME-attached change being accepted, but it makes it more likely | |
194 | that it will be postponed. | |
195 | ||
196 | Exception: If your mailer is mangling patches then someone may ask | |
9847f7e0 | 197 | you to re-send them using MIME, that is OK. |
31408251 | 198 | |
9847f7e0 JH |
199 | Do not PGP sign your patch, at least for now. Most likely, your |
200 | maintainer or other people on the list would not have your PGP | |
201 | key and would not bother obtaining it anyway. Your patch is not | |
202 | judged by who you are; a good patch from an unknown origin has a | |
203 | far better chance of being accepted than a patch from a known, | |
204 | respected origin that is done poorly or does incorrect things. | |
205 | ||
206 | If you really really really really want to do a PGP signed | |
207 | patch, format it as "multipart/signed", not a text/plain message | |
208 | that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is | |
209 | not a text/plain, it's something else. | |
210 | ||
d0c26f0f RR |
211 | Unless your patch is a very trivial and an obviously correct one, |
212 | first send it with "To:" set to the mailing list, with "cc:" listing | |
213 | people who are involved in the area you are touching (the output from | |
214 | "git blame $path" and "git shortlog --no-merges $path" would help to | |
215 | identify them), to solicit comments and reviews. After the list | |
216 | reached a consensus that it is a good idea to apply the patch, re-send | |
217 | it with "To:" set to the maintainer and optionally "cc:" the list for | |
218 | inclusion. Do not forget to add trailers such as "Acked-by:", | |
219 | "Reviewed-by:" and "Tested-by:" after your "Signed-off-by:" line as | |
220 | necessary. | |
04d24455 | 221 | |
31408251 | 222 | |
84ab7b6f | 223 | (4) Sign your work |
31408251 JH |
224 | |
225 | To improve tracking of who did what, we've borrowed the | |
226 | "sign-off" procedure from the Linux kernel project on patches | |
227 | that are being emailed around. Although core GIT is a lot | |
228 | smaller project it is a good discipline to follow it. | |
229 | ||
230 | The sign-off is a simple line at the end of the explanation for | |
231 | the patch, which certifies that you wrote it or otherwise have | |
232 | the right to pass it on as a open-source patch. The rules are | |
233 | pretty simple: if you can certify the below: | |
234 | ||
235 | Developer's Certificate of Origin 1.1 | |
236 | ||
237 | By making a contribution to this project, I certify that: | |
238 | ||
239 | (a) The contribution was created in whole or in part by me and I | |
240 | have the right to submit it under the open source license | |
241 | indicated in the file; or | |
242 | ||
243 | (b) The contribution is based upon previous work that, to the best | |
244 | of my knowledge, is covered under an appropriate open source | |
245 | license and I have the right under that license to submit that | |
246 | work with modifications, whether created in whole or in part | |
247 | by me, under the same open source license (unless I am | |
248 | permitted to submit under a different license), as indicated | |
249 | in the file; or | |
250 | ||
251 | (c) The contribution was provided directly to me by some other | |
252 | person who certified (a), (b) or (c) and I have not modified | |
253 | it. | |
254 | ||
255 | (d) I understand and agree that this project and the contribution | |
256 | are public and that a record of the contribution (including all | |
257 | personal information I submit with it, including my sign-off) is | |
258 | maintained indefinitely and may be redistributed consistent with | |
259 | this project or the open source license(s) involved. | |
260 | ||
261 | then you just add a line saying | |
262 | ||
263 | Signed-off-by: Random J Developer <random@developer.example.org> | |
264 | ||
69945602 PC |
265 | This line can be automatically added by git if you run the git-commit |
266 | command with the -s option. | |
267 | ||
c11c3b56 JH |
268 | Notice that you can place your own Signed-off-by: line when |
269 | forwarding somebody else's patch with the above rules for | |
270 | D-C-O. Indeed you are encouraged to do so. Do not forget to | |
271 | place an in-body "From: " line at the beginning to properly attribute | |
272 | the change to its true author (see (2) above). | |
273 | ||
67275247 MV |
274 | Also notice that a real name is used in the Signed-off-by: line. Please |
275 | don't hide your real name. | |
276 | ||
95b7a41a RR |
277 | If you like, you can put extra tags at the end: |
278 | ||
279 | 1. "Reported-by:" is used to to credit someone who found the bug that | |
280 | the patch attempts to fix. | |
281 | 2. "Acked-by:" says that the person who is more familiar with the area | |
282 | the patch attempts to modify liked the patch. | |
283 | 3. "Reviewed-by:", unlike the other tags, can only be offered by the | |
284 | reviewer and means that she is completely satisfied that the patch | |
285 | is ready for application. It is usually offered only after a | |
286 | detailed review. | |
287 | 4. "Tested-by:" is used to indicate that the person applied the patch | |
288 | and found it to have the desired effect. | |
289 | ||
290 | You can also create your own tag or use one that's in common usage | |
291 | such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". | |
9740d289 | 292 | |
a941fb4a JH |
293 | ------------------------------------------------ |
294 | An ideal patch flow | |
295 | ||
296 | Here is an ideal patch flow for this project the current maintainer | |
297 | suggests to the contributors: | |
298 | ||
299 | (0) You come up with an itch. You code it up. | |
300 | ||
301 | (1) Send it to the list and cc people who may need to know about | |
302 | the change. | |
303 | ||
304 | The people who may need to know are the ones whose code you | |
305 | are butchering. These people happen to be the ones who are | |
306 | most likely to be knowledgeable enough to help you, but | |
307 | they have no obligation to help you (i.e. you ask for help, | |
308 | don't demand). "git log -p -- $area_you_are_modifying" would | |
309 | help you find out who they are. | |
310 | ||
311 | (2) You get comments and suggestions for improvements. You may | |
312 | even get them in a "on top of your change" patch form. | |
313 | ||
314 | (3) Polish, refine, and re-send to the list and the people who | |
315 | spend their time to improve your patch. Go back to step (2). | |
316 | ||
317 | (4) The list forms consensus that the last round of your patch is | |
318 | good. Send it to the list and cc the maintainer. | |
319 | ||
320 | (5) A topic branch is created with the patch and is merged to 'next', | |
321 | and cooked further and eventually graduates to 'master'. | |
322 | ||
323 | In any time between the (2)-(3) cycle, the maintainer may pick it up | |
324 | from the list and queue it to 'pu', in order to make it easier for | |
325 | people play with it without having to pick up and apply the patch to | |
326 | their trees themselves. | |
327 | ||
63cb8215 MM |
328 | ------------------------------------------------ |
329 | Know the status of your patch after submission | |
330 | ||
331 | * You can use Git itself to find out when your patch is merged in | |
332 | master. 'git pull --rebase' will automatically skip already-applied | |
333 | patches, and will let you know. This works only if you rebase on top | |
334 | of the branch in which your patch has been merged (i.e. it will not | |
335 | tell you if your patch is merged in pu if you rebase on top of | |
336 | master). | |
337 | ||
338 | * Read the git mailing list, the maintainer regularly posts messages | |
339 | entitled "What's cooking in git.git" and "What's in git.git" giving | |
340 | the status of various proposed changes. | |
341 | ||
9740d289 JH |
342 | ------------------------------------------------ |
343 | MUA specific hints | |
344 | ||
345 | Some of patches I receive or pick up from the list share common | |
346 | patterns of breakage. Please make sure your MUA is set up | |
347 | properly not to corrupt whitespaces. Here are two common ones | |
348 | I have seen: | |
349 | ||
350 | * Empty context lines that do not have _any_ whitespace. | |
351 | ||
352 | * Non empty context lines that have one extra whitespace at the | |
353 | beginning. | |
354 | ||
9847f7e0 JH |
355 | One test you could do yourself if your MUA is set up correctly is: |
356 | ||
357 | * Send the patch to yourself, exactly the way you would, except | |
358 | To: and Cc: lines, which would not contain the list and | |
359 | maintainer address. | |
360 | ||
361 | * Save that patch to a file in UNIX mailbox format. Call it say | |
362 | a.patch. | |
363 | ||
364 | * Try to apply to the tip of the "master" branch from the | |
365 | git.git public repository: | |
366 | ||
367 | $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply | |
368 | $ git checkout test-apply | |
369 | $ git reset --hard | |
59c8e2cb | 370 | $ git am a.patch |
9847f7e0 JH |
371 | |
372 | If it does not apply correctly, there can be various reasons. | |
373 | ||
374 | * Your patch itself does not apply cleanly. That is _bad_ but | |
375 | does not have much to do with your MUA. Please rebase the | |
376 | patch appropriately. | |
377 | ||
59c8e2cb | 378 | * Your MUA corrupted your patch; "am" would complain that |
51ef1daa | 379 | the patch does not apply. Look at .git/rebase-apply/ subdirectory and |
9847f7e0 JH |
380 | see what 'patch' file contains and check for the common |
381 | corruption patterns mentioned above. | |
382 | ||
383 | * While you are at it, check what are in 'info' and | |
384 | 'final-commit' files as well. If what is in 'final-commit' is | |
385 | not exactly what you would want to see in the commit log | |
386 | message, it is very likely that your maintainer would end up | |
387 | hand editing the log message when he applies your patch. | |
388 | Things like "Hi, this is my first patch.\n", if you really | |
389 | want to put in the patch e-mail, should come after the | |
390 | three-dash line that signals the end of the commit message. | |
391 | ||
9740d289 JH |
392 | |
393 | Pine | |
394 | ---- | |
395 | ||
396 | (Johannes Schindelin) | |
397 | ||
398 | I don't know how many people still use pine, but for those poor | |
399 | souls it may be good to mention that the quell-flowed-text is | |
400 | needed for recent versions. | |
401 | ||
402 | ... the "no-strip-whitespace-before-send" option, too. AFAIK it | |
403 | was introduced in 4.60. | |
404 | ||
405 | (Linus Torvalds) | |
406 | ||
407 | And 4.58 needs at least this. | |
408 | ||
409 | --- | |
410 | diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) | |
411 | Author: Linus Torvalds <torvalds@g5.osdl.org> | |
412 | Date: Mon Aug 15 17:23:51 2005 -0700 | |
413 | ||
414 | Fix pine whitespace-corruption bug | |
415 | ||
416 | There's no excuse for unconditionally removing whitespace from | |
417 | the pico buffers on close. | |
418 | ||
419 | diff --git a/pico/pico.c b/pico/pico.c | |
420 | --- a/pico/pico.c | |
421 | +++ b/pico/pico.c | |
422 | @@ -219,7 +219,9 @@ PICO *pm; | |
a6080a0a JH |
423 | switch(pico_all_done){ /* prepare for/handle final events */ |
424 | case COMP_EXIT : /* already confirmed */ | |
425 | packheader(); | |
9740d289 | 426 | +#if 0 |
a6080a0a | 427 | stripwhitespace(); |
9740d289 | 428 | +#endif |
a6080a0a JH |
429 | c |= COMP_EXIT; |
430 | break; | |
431 | ||
9740d289 | 432 | |
1eb446fa JH |
433 | (Daniel Barkalow) |
434 | ||
435 | > A patch to SubmittingPatches, MUA specific help section for | |
436 | > users of Pine 4.63 would be very much appreciated. | |
437 | ||
438 | Ah, it looks like a recent version changed the default behavior to do the | |
439 | right thing, and inverted the sense of the configuration option. (Either | |
440 | that or Gentoo did it.) So you need to set the | |
441 | "no-strip-whitespace-before-send" option, unless the option you have is | |
442 | "strip-whitespace-before-send", in which case you should avoid checking | |
443 | it. | |
444 | ||
9740d289 JH |
445 | |
446 | Thunderbird | |
447 | ----------- | |
448 | ||
449 | (A Large Angry SCM) | |
450 | ||
1a526d48 JW |
451 | By default, Thunderbird will both wrap emails as well as flag them as |
452 | being 'format=flowed', both of which will make the resulting email unusable | |
453 | by git. | |
454 | ||
9740d289 | 455 | Here are some hints on how to successfully submit patches inline using |
cf6de18a | 456 | Thunderbird. |
9740d289 | 457 | |
1a526d48 JW |
458 | There are two different approaches. One approach is to configure |
459 | Thunderbird to not mangle patches. The second approach is to use | |
460 | an external editor to keep Thunderbird from mangling the patches. | |
461 | ||
462 | Approach #1 (configuration): | |
463 | ||
464 | This recipe is current as of Thunderbird 2.0.0.19. Three steps: | |
465 | 1. Configure your mail server composition as plain text | |
466 | Edit...Account Settings...Composition & Addressing, | |
467 | uncheck 'Compose Messages in HTML'. | |
468 | 2. Configure your general composition window to not wrap | |
469 | Edit..Preferences..Composition, wrap plain text messages at 0 | |
470 | 3. Disable the use of format=flowed | |
471 | Edit..Preferences..Advanced..Config Editor. Search for: | |
472 | mailnews.send_plaintext_flowed | |
473 | toggle it to make sure it is set to 'false'. | |
474 | ||
475 | After that is done, you should be able to compose email as you | |
476 | otherwise would (cut + paste, git-format-patch | git-imap-send, etc), | |
477 | and the patches should not be mangled. | |
478 | ||
479 | Approach #2 (external editor): | |
480 | ||
9740d289 JH |
481 | This recipe appears to work with the current [*1*] Thunderbird from Suse. |
482 | ||
483 | The following Thunderbird extensions are needed: | |
484 | AboutConfig 0.5 | |
485 | http://aboutconfig.mozdev.org/ | |
ff62b7f3 LS |
486 | External Editor 0.7.2 |
487 | http://globs.org/articles.php?lng=en&pg=8 | |
9740d289 JH |
488 | |
489 | 1) Prepare the patch as a text file using your method of choice. | |
490 | ||
491 | 2) Before opening a compose window, use Edit->Account Settings to | |
492 | uncheck the "Compose messages in HTML format" setting in the | |
493 | "Composition & Addressing" panel of the account to be used to send the | |
494 | patch. [*2*] | |
495 | ||
496 | 3) In the main Thunderbird window, _before_ you open the compose window | |
497 | for the patch, use Tools->about:config to set the following to the | |
498 | indicated values: | |
499 | mailnews.send_plaintext_flowed => false | |
cf6de18a | 500 | mailnews.wraplength => 0 |
9740d289 JH |
501 | |
502 | 4) Open a compose window and click the external editor icon. | |
503 | ||
504 | 5) In the external editor window, read in the patch file and exit the | |
505 | editor normally. | |
506 | ||
507 | 6) Back in the compose window: Add whatever other text you wish to the | |
508 | message, complete the addressing and subject fields, and press send. | |
509 | ||
510 | 7) Optionally, undo the about:config/account settings changes made in | |
511 | steps 2 & 3. | |
512 | ||
513 | ||
514 | [Footnotes] | |
515 | *1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse | |
516 | 9.3 professional updates. | |
517 | ||
518 | *2* It may be possible to do this with about:config and the following | |
519 | settings but I haven't tried, yet. | |
520 | mail.html_compose => false | |
521 | mail.identity.default.compose_html => false | |
522 | mail.identity.id?.compose_html => false | |
523 | ||
0c3d26d2 LS |
524 | (Lukas Sandström) |
525 | ||
526 | There is a script in contrib/thunderbird-patch-inline which can help | |
527 | you include patches with Thunderbird in an easy way. To use it, do the | |
528 | steps above and then use the script as the external editor. | |
e30b217b | 529 | |
e30b217b JH |
530 | Gnus |
531 | ---- | |
532 | ||
533 | '|' in the *Summary* buffer can be used to pipe the current | |
534 | message to an external program, and this is a handy way to drive | |
535 | "git am". However, if the message is MIME encoded, what is | |
536 | piped into the program is the representation you see in your | |
537 | *Article* buffer after unwrapping MIME. This is often not what | |
538 | you would want for two reasons. It tends to screw up non ASCII | |
539 | characters (most notably in people's names), and also | |
540 | whitespaces (fatal in patches). Running 'C-u g' to display the | |
541 | message in raw form before using '|' to run the pipe can work | |
542 | this problem around. | |
543 | ||
451fd65a MB |
544 | |
545 | KMail | |
546 | ----- | |
547 | ||
548 | This should help you to submit patches inline using KMail. | |
549 | ||
550 | 1) Prepare the patch as a text file. | |
551 | ||
552 | 2) Click on New Mail. | |
553 | ||
554 | 3) Go under "Options" in the Composer window and be sure that | |
555 | "Word wrap" is not set. | |
556 | ||
557 | 4) Use Message -> Insert file... and insert the patch. | |
558 | ||
559 | 5) Back in the compose window: add whatever other text you wish to the | |
560 | message, complete the addressing and subject fields, and press send. | |
c2163c6a TPW |
561 | |
562 | ||
563 | Gmail | |
564 | ----- | |
565 | ||
50dffd4e JT |
566 | GMail does not appear to have any way to turn off line wrapping in the web |
567 | interface, so this will mangle any emails that you send. You can however | |
811dd906 | 568 | use "git send-email" and send your patches through the GMail SMTP server, or |
e498257d | 569 | use any IMAP email client to connect to the google IMAP server and forward |
df5753c4 | 570 | the emails through that. |
50dffd4e | 571 | |
e498257d MG |
572 | To use "git send-email" and send your patches through the GMail SMTP server, |
573 | edit ~/.gitconfig to specify your account settings: | |
574 | ||
575 | [sendemail] | |
576 | smtpencryption = tls | |
577 | smtpserver = smtp.gmail.com | |
578 | smtpuser = user@gmail.com | |
579 | smtppass = p4ssw0rd | |
580 | smtpserverport = 587 | |
581 | ||
582 | Once your commits are ready to be sent to the mailing list, run the | |
583 | following commands: | |
584 | ||
585 | $ git format-patch --cover-letter -M origin/master -o outgoing/ | |
586 | $ edit outgoing/0000-* | |
587 | $ git send-email outgoing/* | |
588 | ||
df5753c4 | 589 | To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your |
c2163c6a TPW |
590 | account settings: |
591 | ||
592 | [imap] | |
593 | folder = "[Gmail]/Drafts" | |
594 | host = imaps://imap.gmail.com | |
595 | user = user@gmail.com | |
596 | pass = p4ssw0rd | |
597 | port = 993 | |
598 | sslverify = false | |
599 | ||
50dffd4e JT |
600 | You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error |
601 | that the "Folder doesn't exist". | |
602 | ||
df5753c4 | 603 | Once your commits are ready to be sent to the mailing list, run the |
e498257d | 604 | following commands: |
c2163c6a | 605 | |
df5753c4 | 606 | $ git format-patch --cover-letter -M --stdout origin/master | git imap-send |
c2163c6a | 607 | |
df5753c4 JH |
608 | Just make sure to disable line wrapping in the email client (GMail web |
609 | interface will line wrap no matter what, so you need to use a real | |
610 | IMAP client). | |
c2163c6a | 611 |