diff options
Diffstat (limited to 'submitting-patches')
| -rw-r--r-- | submitting-patches | 20 |
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. |