summaryrefslogtreecommitdiff
path: root/Documentation/SubmittingPatches
diff options
context:
space:
mode:
authorJohannes Schindelin <Johannes.Schindelin@gmx.de>2007-03-05 15:37:54 (GMT)
committerJunio C Hamano <junkio@cox.net>2007-03-05 22:49:22 (GMT)
commit56333bac66ccdefa3f6d67f78da9f5267119c4a6 (patch)
treeaf37fdb1c68833a72dda87ec1152c8e28b27892f /Documentation/SubmittingPatches
parent7193db3685b71be3e93aaac785bdc554d91d2167 (diff)
downloadgit-56333bac66ccdefa3f6d67f78da9f5267119c4a6.zip
git-56333bac66ccdefa3f6d67f78da9f5267119c4a6.tar.gz
git-56333bac66ccdefa3f6d67f78da9f5267119c4a6.tar.bz2
Begin SubmittingPatches with a check list
It seems that some people prefer a short list to a long text. But even for the latter group, a quick reminder list is useful. So, add a check list to Documentation/SubmittingPatches of what to do to get your patch accepted. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'Documentation/SubmittingPatches')
-rw-r--r--Documentation/SubmittingPatches27
1 files changed, 27 insertions, 0 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 285781d..131bcff 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -1,3 +1,30 @@
+Checklist (and a short version for the impatient):
+
+ - make commits of logical units
+ - check for unnecessary whitespace with "git diff --check"
+ before committing
+ - do not check in commented out code or unneeded files
+ - provide a meaningful commit message
+ - the first line of the commit message should be a short
+ description and should skip the full stop
+ - if you want your work included in git.git, add a
+ "Signed-off-by: Your Name <your@email.com>" line to the
+ commit message (or just use the option "-s" when
+ committing) to confirm that you agree to the Developer's
+ Certificate of Origin
+ - do not PGP sign your patch
+ - use "git format-patch -M" to create the patch
+ - do not attach your patch, but read in the mail
+ body, unless you cannot teach your mailer to
+ leave the formatting of the patch alone.
+ - be careful doing cut & paste into your mailer, not to
+ corrupt whitespaces.
+ - provide additional information (which is unsuitable for
+ the commit message) between the "---" and the diffstat
+ - send the patch to the list _and_ the maintainer
+
+Long version:
+
I started reading over the SubmittingPatches document for Linux
kernel, primarily because I wanted to have a document similar to
it for the core GIT to make sure people understand what they are