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>
This commit is contained in:
parent
7193db3685
commit
56333bac66
@ -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
|
I started reading over the SubmittingPatches document for Linux
|
||||||
kernel, primarily because I wanted to have a document similar to
|
kernel, primarily because I wanted to have a document similar to
|
||||||
it for the core GIT to make sure people understand what they are
|
it for the core GIT to make sure people understand what they are
|
||||||
|
Loading…
Reference in New Issue
Block a user