Subject: + submittingpatches-document-the-use-of-git.patch added to -mm tree To: josh@xxxxxxxxxxxxxxxx,bp@xxxxxxx,rdunlap@xxxxxxxxxxxxx,rob@xxxxxxxxxxx From: akpm@xxxxxxxxxxxxxxxxxxxx Date: Mon, 24 Feb 2014 15:13:02 -0800 The patch titled Subject: SubmittingPatches: document the use of git has been added to the -mm tree. Its filename is submittingpatches-document-the-use-of-git.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/submittingpatches-document-the-use-of-git.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/submittingpatches-document-the-use-of-git.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Josh Triplett <josh@xxxxxxxxxxxxxxxx> Subject: SubmittingPatches: document the use of git 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@xxxxxxxxxxxxxxxx> Acked-by: Borislav Petkov <bp@xxxxxxx> Cc: Rob Landley <rob@xxxxxxxxxxx> Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> --- Documentation/SubmittingPatches | 33 +++++++++++++++--------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff -puN Documentation/SubmittingPatches~submittingpatches-document-the-use-of-git Documentation/SubmittingPatches --- a/Documentation/SubmittingPatches~submittingpatches-document-the-use-of-git +++ a/Documentation/SubmittingPatches @@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a 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 CH 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 an 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: - -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 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. + +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. _ Patches currently in -mm which might be from josh@xxxxxxxxxxxxxxxx are mm-compactionc-mark-function-as-static.patch mm-memoryc-mark-functions-as-static.patch mm-mmapc-mark-function-as-static.patch mm-process_vm_accessc-mark-function-as-static.patch mm-process_vm_accessc-mark-function-as-static-fix.patch mm-page_cgroupc-mark-functions-as-static.patch mm-nobootmemc-mark-function-as-static.patch include-linux-mmh-remove-ifdef-condition.patch include-linux-syscallsh-add-sys32_quotactl-prototype.patch fs-kernel-permit-disabling-the-uselib-syscall.patch fs-kernel-permit-disabling-the-uselib-syscall-v2.patch submittingpatches-add-style-recommendation-to-use-imperative-descriptions.patch submittingpatches-add-recommendation-for-mailing-list-references.patch submittingpatches-document-the-use-of-git.patch lglock-map-to-spinlock-when-config_smp.patch fs-reiserfs-move-prototype-declaration-to-header-file.patch include-linux-crash_dumph-add-vmcore_cleanup-prototype.patch include-linux-crash_dumph-add-vmcore_cleanup-prototype-fix.patch kconfig-make-allnoconfig-disable-options-behind-embedded-and-expert.patch linux-next.patch -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html