Junio C Hamano <gits...@pobox.com> wrote: > 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.tay...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
