summaryrefslogtreecommitdiff
path: root/Documentation/SubmittingPatches
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-02-18 00:15:26 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-02-18 00:15:26 (GMT)
commit45d2b286acf4a1191e6199c41a034cb0677a0965 (patch)
treeb9f6d5f4f4f3e6e3057dcee7d793ad6ab25c8b32 /Documentation/SubmittingPatches
parent020e3c1ee6924edbcf61b6e401058fa06ddbd406 (diff)
downloadgit-45d2b286acf4a1191e6199c41a034cb0677a0965.zip
git-45d2b286acf4a1191e6199c41a034cb0677a0965.tar.gz
git-45d2b286acf4a1191e6199c41a034cb0677a0965.tar.bz2
SubmittingPatches: note on whitespaces
Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'Documentation/SubmittingPatches')
-rw-r--r--Documentation/SubmittingPatches30
1 files changed, 19 insertions, 11 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 9ccb8f7..318b04f 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -4,8 +4,8 @@ it for the core GIT to make sure people understand what they are
doing when they write "Signed-off-by" line.
But the patch submission requirements are a lot more relaxed
-here, because the core GIT is thousand times smaller ;-). So
-here is only the relevant bits.
+here on the technical/contents front, because the core GIT is
+thousand times smaller ;-). So here is only the relevant bits.
(1) Make separate commits for logically separate changes.
@@ -18,13 +18,19 @@ repository. It is a good discipline.
Describe the technical detail of the change(s).
-If your description starts to get long, that's a sign that you
+If your description starts to get too long, that's a sign that you
probably need to split up your commit to finer grained pieces.
+Oh, another thing. I am picky about whitespaces. Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in templates/hooks--pre-commit.
-(2) Generate your patch using git/cogito out of your commits.
-git diff tools generate unidiff which is the preferred format.
+(2) Generate your patch using git tools out of your commits.
+
+git based diff tools (git, Cogito, and StGIT included) generate
+unidiff which is the preferred format.
+
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
receiving end can handle them just fine.
@@ -33,20 +39,22 @@ Please make sure your patch does not include any extra files
which do not belong in a patch submission. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the "master"
-branch head.
+branch head. If you are preparing a work based on "next" branch,
+that is fine, but please mark it as such.
(3) Sending your patches.
-People on the git mailing list needs to be able to read and
+People on the git mailing list need to be able to read and
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
-your code. For this reason, all patches should be submitting
-e-mail "inline". WARNING: Be wary of your MUAs word-wrap
-corrupting your patch. Do not cut-n-paste your patch.
+your code. For this reason, all patches should be submited
+"inline". 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.
-It is common convention to prefix your subject line with
+It is a common convention to prefix your subject line with
[PATCH]. This lets people easily distinguish patches from other
e-mail discussions.