linux-kernel - Re: [PATCH 3/3] SubmittingPatches: Document the use of git

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 16 Dec 2013 18:58:50 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	Randy Dunlap <rdunlap@...radead.org>
Cc:	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Rob Landley <rob@...dley.net>
Subject: Re: [PATCH 3/3] SubmittingPatches: Document the use of git

On Mon, Dec 16, 2013 at 11:32:08AM -0800, Randy Dunlap wrote:
> On 12/16/13 11:30, Randy Dunlap wrote:
> > On 12/15/13 12:59, Josh Triplett wrote:
> >> 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@...htriplett.org>
> >> ---
> >>  Documentation/SubmittingPatches | 31 ++++++++++++++++---------------
> >>  1 file changed, 16 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> >> index 53e6590..fdad7d1 100644
> >> --- a/Documentation/SubmittingPatches
> >> +++ b/Documentation/SubmittingPatches
> >> @@ -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:
> >> -
> > 
> > I object to the removal of the quilt reference.  git is overkill for
> > simple patches.
> 
> bah humbug.  Sorry, I missed the movement of the quilt reference.

Yeah, I intentionally kept the reference to quilt, on the theory that a
user who can't use git for some reason is better off using quilt than
trying to manage and reorganize patches by hand.  I just rearranged it
slightly.  "git diff --color-words" was a far better way to review this
particular change.

> >> -Quilt:
> >> -http://savannah.nongnu.org/projects/quilt
> >> +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.
> >>  
> >> -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.
> >>
> > 
> > 
> 
> 
> -- 
> ~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/