Evolinx/bottle
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update submitting-patches file.

Browse Source 
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>
This commit is contained in:
Xavier Chantry 2008-07-27 17:45:52 +02:00 committed by Dan McGee
parent 6ede1a5af0
commit 5d6788b36e
1 changed files with 22 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
submitting-patches
View File

@ -4,34 +4,38 @@ Pacman - Submitting Patches
This document is here mainly to make my job easier, and is more of a guideline, 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. 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. "SubmittingPatches" file.
Creating your patch Creating your patch
------------------- -------------------
Most of this was more relevant before we switched to GIT for version control. Patches need to be submitted in GIT format. So for getting started, you will
However, much of it is still applicable and should be followed. Some notes have to read some git guides first, to learn how to fetch pacman git repo, how
have been added to make this a bit more up-to-date with the GIT workflow. 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 The -s allows you to credit yourself by adding a "Signed Off By" line to
submitted patches. If you are working on your own git branch, then GIT indicate who has "signed" the patch - who has approved it.
formatted patches are perfectly acceptable.
* Please try to make patches "p1 applicable" Signed-off-by: Aaron Griffin <aaron@archlinux.org>
This means that if you are patching file "lib/libalpm/alpm.h", I should be Please use your real name and email address. Feel free to "scramble" the
able to apply your patch while passing the -p1 argument to 'patch'. The diff address if you're afraid of spam.
header should look like so:
--- ORIGINAL_DIR/lib/libalpm/alpm.h * Describe your patch.
+++ NEW_DIR/lib/libalpm/alpm.h
With '-p1' the ORIGINAL_DIR and NEW_DIR arguments are stripped. GIT produces It helps if you describe the changes of the patch in the git commit log.
p1 formatted patches by default. This allows others to see what you intended so as to compare it to
what was actually done, and allows better feedback.
* 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 Submitting your patch
@ -41,8 +45,7 @@ Submitting your patch
* Send the patch to the pacman-dev mailing list * Send the patch to the pacman-dev mailing list
The mailing list is the primary queue for review and acceptance. Here you 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 will get feedback, and let me know the details of your patch.
if you add "[patch]" to the beginning of your Subject line.
* No MIME, no links, no compression, no attachments. Just plain text. * 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 it allows easier review "at a glance", and most importantly, it allows people
to comment on exact lines of the patch in reply emails. 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 git send-email allows you to send git formatted patches in plain text easily.
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>
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 After you submit