Re: [Documentation/RFC] Submitting Patches
- From
- Cody Taylor <cody.taylor@maternityneighborhood.com>
- Date
- Mar 13, 2015, 08:18 UTC
- Message-ID
- <CAHWMk2ZE1bY0ABcMRTqHGW3oY-oWXaaKdaBOzo2rVyZjJPRzQQ@mail.gmail.com>
Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> Subject: SubmittingPatches: nudge to use send-email > > In step "(4) Sending your patches", we instruct users to do an > inline patch, avoid breaking whitespaces, avoid attachments, > use [PATCH v2] for second round, etc., all of which send-email > knows how to do.
The idea that `git send-email` does all of the suggestions really should be reflected in the documentation.
> Mention send-email at least once to gently nudge the user to (learn > to) use it.
If the tool is good, do not tippy toe around the subject. Write plain text e-mail is a strange enough experience today, the documentation should plainly state that "git send-email" is likely the easiest solution to sending a patch or series of patches.
Suggesting: Cody A Taylor <cody.taylor@maternityneighborhood.com> --- Documentation/SubmittingPatches | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index ef0eeb40cd22..702f1ace08ae 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -136,6 +136,14 @@ that is fine, but please mark it as such. (4) Sending your patches. +The "git format-patch" and "git send-email" commands are +complemtary to one another. They are optimized to make the work +flow of sending patches much easier. Primarily, using these +commands avoids the need to re-learn your existing e-mail client +that is optimized for "multipart/*" mime type e-mails. Using +these tools you will midigate the simple problems that cause poorly +formatted e-mails. + People on the Git mailing list need to be able to read and comment on the changes you are submitting. It is important for a developer to be able to "quote" your changes, using standard -- v2.3.2