Update 'submitting-patches'

Signed-off-by: Dan McGee <dan@archlinux.org>

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.