diff options
Diffstat (limited to 'documentation/contributor-guide/submit-changes.rst')
-rw-r--r-- | documentation/contributor-guide/submit-changes.rst | 29 |
1 files changed, 20 insertions, 9 deletions
diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst index 314b41bb63..afed30717b 100644 --- a/documentation/contributor-guide/submit-changes.rst +++ b/documentation/contributor-guide/submit-changes.rst | |||
@@ -340,6 +340,25 @@ Here is the general procedure on how to create patches to be sent through email: | |||
340 | Sending the Patches via Email | 340 | Sending the Patches via Email |
341 | ============================= | 341 | ============================= |
342 | 342 | ||
343 | Using Git to Send Patches | ||
344 | ------------------------- | ||
345 | |||
346 | To submit patches through email, it is very important that you send them | ||
347 | without any whitespace or HTML formatting that either you or your mailer | ||
348 | introduces. The maintainer that receives your patches needs to be able | ||
349 | to save and apply them directly from your emails, using the ``git am`` | ||
350 | command. | ||
351 | |||
352 | Using the ``git send-email`` command is the only error-proof way of | ||
353 | sending your patches using email since there is no risk of compromising | ||
354 | whitespace in the body of the message, which can occur when you use | ||
355 | your own mail client. It will also properly include your patches | ||
356 | as inline attachments, which is not easy to do with standard e-mail | ||
357 | clients without breaking lines. | ||
358 | |||
359 | Setting up Git to Send Email | ||
360 | ---------------------------- | ||
361 | |||
343 | Depending on the components changed, you need to submit the email to a | 362 | Depending on the components changed, you need to submit the email to a |
344 | specific mailing list. For some guidance on which mailing list to use, | 363 | specific mailing list. For some guidance on which mailing list to use, |
345 | see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" | 364 | see the ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" |
@@ -350,15 +369,7 @@ section above. | |||
350 | 369 | ||
351 | The ``git send-email`` command sends email by using a local or remote | 370 | The ``git send-email`` command sends email by using a local or remote |
352 | Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or | 371 | Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or |
353 | through a direct ``smtp`` configuration in your Git ``~/.gitconfig`` | 372 | through a direct ``smtp`` configuration in your Git ``~/.gitconfig`` file. |
354 | file. If you are submitting patches through email only, it is very | ||
355 | important that you submit them without any whitespace or HTML | ||
356 | formatting that either you or your mailer introduces. The maintainer | ||
357 | that receives your patches needs to be able to save and apply them | ||
358 | directly from your emails. A good way to verify that what you are | ||
359 | sending will be applicable by the maintainer is to do a dry run and | ||
360 | send them to yourself and then save and apply them as the maintainer | ||
361 | would. | ||
362 | 373 | ||
363 | The ``git send-email`` command is the preferred method for sending | 374 | The ``git send-email`` command is the preferred method for sending |
364 | your patches using email since there is no risk of compromising | 375 | your patches using email since there is no risk of compromising |