Cody Taylor <cody.tay...@maternityneighborhood.com> writes:
> Anyway, this brings up the point that `git send-email` should at least
> get a mention in the "Documentation/SubmittingPatches" file. Likely
> the best place for this is a paragraph after `git format-patch` is
> mentioned in section 4 ("Sending your patches.").
[removed others who are not to be blamed for the lack of doc from cc]
I very much agree with that---actually I am somewhat surprised that
the documentation doesn't do so already.
Perhaps something like this?
-- >8 --
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.
Mention send-email at least once to gently nudge the user to (learn
to) use it.
Suggested-by: Cody Taylor <cody.tay...@maternityneighborhood.com>
Signed-off-by: Junio C Hamano <gits...@pobox.com>
---
Documentation/SubmittingPatches | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index ef0eeb4..2b10569 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -154,7 +154,8 @@ you send off a message in the correct encoding.
WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch; you can
-lose tabs that way if you are not careful.
+lose tabs that way if you are not careful. If you can use the
+"git send-email" command, please do so.
It is a common convention to prefix your subject line with
[PATCH]. This lets people easily distinguish patches from other
--
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
