summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2008-02-03 17:00:16 -0800
committerJunio C Hamano <gitster@pobox.com>2008-02-05 00:39:03 -0800
commit0b0599402d0e4354c60d192eb926f46577040a29 (patch)
tree05396080bae47a8af3d591633486db350d6d394d /Documentation
parent4e891acf679c0020b61889447f8f412324aeffa9 (diff)
downloadgit-0b0599402d0e4354c60d192eb926f46577040a29.tar.gz
Documentation/SubmittingPatches: discuss first then submit
This is something I've had in mind for some time. I get enough e-mails as-is, and I suspect the workflow to get list members involved would work better if we get the discussion concluded on the list first before patches hit my tree (even 'next'). Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/SubmittingPatches9
1 files changed, 5 insertions, 4 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index cd80148111..7900223735 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -34,9 +34,9 @@ Checklist (and a short version for the impatient):
- if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the
- maintainer (gitster@pobox.com). If you use
- git-send-email(1), please test it first by sending
- email to yourself.
+ maintainer (gitster@pobox.com) if (and only if) the patch
+ is ready for inclusion. If you use git-send-email(1),
+ please test it first by sending email to yourself.
Long version:
@@ -162,7 +162,8 @@ Note that your maintainer does not necessarily read everything
on the git mailing list. If your patch is for discussion first,
send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send
-it "To:" the maintainer and optionally "cc:" the list.
+it "To:" the maintainer and optionally "cc:" the list for
+inclusion.
Also note that your maintainer does not actively involve himself in
maintaining what are in contrib/ hierarchy. When you send fixes and