summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--submitting-patches20
1 files changed, 16 insertions, 4 deletions
diff --git a/submitting-patches b/submitting-patches
index 0fe54ef6..725b1ea1 100644
--- a/submitting-patches
+++ b/submitting-patches
@@ -9,10 +9,15 @@ NOTE: Much of this is paraphrased from the kernel documentation's
Creating your patch:
+Most of this was more relevant before we switched to GIT for version control.
+However, much of it is still applicable and should be followed. Some notes
+have been added to make this a bit more up-to-date with the GIT workflow.
+
* Use "diff -up" or "diff -uprN" to create patches.
These options make the diff easier to read for those of us who try to review
- submitted patches.
+ submitted patches. If you are working on your own git branch, then GIT
+ formatted patches are perfectly acceptable.
* Please try to make patches "p1 applicable"
@@ -23,7 +28,8 @@ Creating your patch:
--- ORIGINAL_DIR/lib/libalpm/alpm.h
+++ NEW_DIR/lib/libalpm/alpm.h
- With '-p1' the ORIGINAL_DIR and NEW_DIR arguments are stripped.
+ With '-p1' the ORIGINAL_DIR and NEW_DIR arguments are stripped. GIT produces
+ p1 formatted patches by default.
Submitting your patch:
@@ -48,7 +54,9 @@ Submitting your patch:
Before the actual diff begins, it helps if you describe the changes in the
patch. This allows others to see what you intended so as to compare it to
- what was actually done, and allows better feedback
+ what was actually done, and allows better feedback. If you use
+ 'git-format-patch' to create your patch, then your commit message will
+ be shown above the patch by default.
* Credit yourself
@@ -58,7 +66,7 @@ Submitting your patch:
Signed-off-by: Aaron Griffin <aaron@archlinux.org>
Please use your real name and email address. Feel free to "scramble" the
- address if you're afraid of spam.
+ address if you're afraid of spam. 'git commit -s' makes this easy.
After you submit:
@@ -66,3 +74,7 @@ After you submit:
Any feedback you get, positive or negative, has nothing to do with you. If a
patch is rejected, try taking the suggestions into account and re-submitting.
+ We welcome most submissions here, and some may take a bit longer to get
+ looked over than others. If you think your patch got lost in the shuffle,
+ send another email to the list in reply to the original asking if anyone has
+ looked at it yet.