Browse Source

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>
maint
Johannes Schindelin 18 years ago committed by Junio C Hamano
parent
commit
56333bac66
  1. 27
      Documentation/SubmittingPatches

27
Documentation/SubmittingPatches

@ -1,3 +1,30 @@ @@ -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

Loading…
Cancel
Save