summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorXavier Chantry <shiningxc@gmail.com>2008-07-27 17:45:52 +0200
committerDan McGee <dan@archlinux.org>2008-07-30 05:24:42 +0200
commit5d6788b36e8e2a6b883c841f23e257b9e9153687 (patch)
tree03b8fd7fdcc7587ba6b23d1be7e0780d36e6fb96
parent6ede1a5af07e437d16c6fd4cc876ffb3cec4940b (diff)
downloadpacman-5d6788b36e8e2a6b883c841f23e257b9e9153687.tar.gz
pacman-5d6788b36e8e2a6b883c841f23e257b9e9153687.tar.xz
Update submitting-patches file.
The submitting patches page needed a bit of updating. It was currently a mash-up between the pre and post git eras. Signed-off-by: Xavier Chantry <shiningxc@gmail.com> Signed-off-by: Dan McGee <dan@archlinux.org>
-rw-r--r--submitting-patches61
1 files changed, 22 insertions, 39 deletions
diff --git a/submitting-patches b/submitting-patches
index 02cde30f..452a1b85 100644
--- a/submitting-patches
+++ b/submitting-patches
@@ -4,34 +4,38 @@ Pacman - Submitting Patches
This document is here mainly to make my job easier, and is more of a guideline,
and not a strict set of rules. Please try to follow as much as you can.
-NOTE: Much of this is paraphrased from the kernel documentation's
+NOTE: Some of this is paraphrased from the kernel documentation's
"SubmittingPatches" file.
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.
+Patches need to be submitted in GIT format. So for getting started, you will
+have to read some git guides first, to learn how to fetch pacman git repo, how
+to configure your name and email adress, how to create a branch, a commit, and
+finally your patch.
--
-* Use "diff -up" or "diff -uprN" to create patches.
+* use git commit -s for creating a commit of your changes.
-These options make the diff easier to read for those of us who try to review
-submitted patches. If you are working on your own git branch, then GIT
-formatted patches are perfectly acceptable.
+The -s allows you to credit yourself by adding a "Signed Off By" line to
+indicate who has "signed" the patch - who has approved it.
+
+ Signed-off-by: Aaron Griffin <aaron@archlinux.org>
-* Please try to make patches "p1 applicable"
+Please use your real name and email address. Feel free to "scramble" the
+address if you're afraid of spam.
-This means that if you are patching file "lib/libalpm/alpm.h", I should be
-able to apply your patch while passing the -p1 argument to 'patch'. The diff
-header should look like so:
+* Describe your patch.
- --- ORIGINAL_DIR/lib/libalpm/alpm.h
- +++ NEW_DIR/lib/libalpm/alpm.h
+It helps if you describe the changes of the patch in the git commit log.
+This allows others to see what you intended so as to compare it to
+what was actually done, and allows better feedback.
-With '-p1' the ORIGINAL_DIR and NEW_DIR arguments are stripped. GIT produces
-p1 formatted patches by default.
+* Use git format-patch to create patches.
+
+Your commit message will be shown above the patch by default when you will use
+`git-format-patch`, including the signoff line.
--
Submitting your patch
@@ -41,8 +45,7 @@ Submitting your patch
* Send the patch to the pacman-dev mailing list
The mailing list is the primary queue for review and acceptance. Here you
-will get feedback, and let me know the details of your patch. It also helps
-if you add "[patch]" to the beginning of your Subject line.
+will get feedback, and let me know the details of your patch.
* No MIME, no links, no compression, no attachments. Just plain text.
@@ -51,28 +54,8 @@ reasons for this. Firstly, it makes them easier to read with any mail reader,
it allows easier review "at a glance", and most importantly, it allows people
to comment on exact lines of the patch in reply emails.
-It is important to know that the diff format ignores plain text before (and
-after) the main diff itself. If you directly insert your patch into an email,
-you can safely add lines above it describing your patch.
-
-* Describe 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. If you use
-`git-format-patch` to create your patch, then your commit message will
-be shown above the patch by default.
-
-* Credit yourself
-
-Just like with the kernel, it helps if you add a "Signed Off By" line to
-indicate who has "signed" the patch - who has approved it.
-
- Signed-off-by: Aaron Griffin <aaron@archlinux.org>
-
+git send-email allows you to send git formatted patches in plain text easily.
-Please use your real name and email address. Feel free to "scramble" the
-address if you're afraid of spam. `git commit -s` makes this easy.
--
After you submit