leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

SubmittingPatches: document the use of git

Browse Source 
Most of the mechanical portions of SubmittingPatches exist to help patch
submitters replicate the output of git.  Mention this explicitly, both
as a reminder that git will help with this process, and as signposting
to let git users know what they can safely skip.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Rob Landley <rob@landley.net>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Josh Triplett 2014-04-03 14:48:30 -07:00 committed by Linus Torvalds
parent 9547c706d2
commit 8e3072a23f
1 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
Documentation/SubmittingPatches
View File

@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to check
before submitting code. If you are submitting a driver, also read
Documentation/SubmittingDrivers.
Many of these steps describe the default behavior of the git version
control system; if you use git to prepare your patches, you'll find much
of the mechanical work done for you, though you'll still need to prepare
and document a sensible set of patches.
--------------------------------------------
SECTION 1 - CREATING AND SENDING YOUR CHANGE
@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
1) "diff -up"
------------
Use "diff -up" or "diff -uprN" to create patches.
Use "diff -up" or "diff -uprN" to create patches. git generates patches
in this form by default; if you're using git, you can skip this section
entirely.
All changes to the Linux kernel occur in the form of patches, as
generated by diff(1). When creating your patch, make sure to create it
@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
generated it with diff(1), to ensure accuracy.
If your changes produce a lot of deltas, you may want to look into
splitting them into individual patches which modify things in
logical stages. This will facilitate easier reviewing by other
kernel developers, very important if you want your patch accepted.
There are a number of scripts which can aid in this:
If your changes produce a lot of deltas, you need to split them into
individual patches which modify things in logical stages; see section
#3. This will facilitate easier reviewing by other kernel developers,
very important if you want your patch accepted.
Quilt:
http://savannah.nongnu.org/projects/quilt
Andrew Morton's patch scripts:
http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
Instead of these scripts, quilt is the recommended patch management
tool (see above).
If you're using git, "git rebase -i" can help you with this process. If
you're not using git, quilt <http://savannah.nongnu.org/projects/quilt>
is another popular alternative.
@ -607,7 +607,8 @@ patch.
If you are going to include a diffstat after the "---" marker, please
use diffstat options "-p 1 -w 70" so that filenames are listed from
the top of the kernel source tree and don't use too much horizontal
space (easily fit in 80 columns, maybe with some indentation).
space (easily fit in 80 columns, maybe with some indentation). (git
generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.