diff options
author | Xavier Chantry <shiningxc@gmail.com> | 2008-07-27 17:45:52 +0200 |
---|---|---|
committer | Dan McGee <dan@archlinux.org> | 2008-07-30 05:24:42 +0200 |
commit | 5d6788b36e8e2a6b883c841f23e257b9e9153687 (patch) | |
tree | 03b8fd7fdcc7587ba6b23d1be7e0780d36e6fb96 /submitting-patches | |
parent | 6ede1a5af07e437d16c6fd4cc876ffb3cec4940b (diff) | |
download | pacman-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>
Diffstat (limited to 'submitting-patches')
-rw-r--r-- | submitting-patches | 61 |
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 |