[PATCH v4 19/29] Documentation/SubmittingPatches: convert it to ReST markup

[Mauro Carvalho Chehab]

- Change the sections to use ReST markup;
- Add cross-references where needed;
- convert aspas to verbatim text;
- use code block tags;
- make Sphinx happy.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmittingPatches | 207 
 1 file changed, 105 insertions(+), 102 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8c79f1d53731..04a4284d8ee4 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -1,9 +1,6 @@
 
-   How to Get Your Change Into the Linux Kernel
-   or
-   Care And Operation Of Your Linus Torvalds
-
-
+How to Get Your Change Into the Linux Kernel or Care And Operation Of Your 
Linus Torvalds
+=
 
 For a person or company who wishes to submit a change to the Linux
 kernel, the process can sometimes be daunting if you're not familiar
@@ -24,9 +21,8 @@ of the mechanical work done for you, though you'll still need 
to prepare
 and document a sensible set of patches.  In general, use of git will make
 your life as a kernel developer easier.
 
-
-SECTION 1 - CREATING AND SENDING YOUR CHANGE
-
+Creating and Sending your Change
+
 
 
 0) Obtain a current source tree
@@ -34,35 +30,35 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
 
 If you do not have a repository with the current kernel source handy, use
 git to obtain one.  You'll want to start with the mainline repository,
-which can be grabbed with:
+which can be grabbed with::
 
-  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
+  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 Note, however, that you may not want to develop against the mainline tree
 directly.  Most subsystem maintainers run their own trees and want to see
-patches prepared against those trees.  See the "T:" entry for the subsystem
+patches prepared against those trees.  See the **T:** entry for the subsystem
 in the MAINTAINERS file to find that tree, or simply ask the maintainer if
 the tree is not listed there.
 
 It is still possible to download kernel releases via tarballs (as described
 in the next section), but that is the hard way to do kernel development.
 
-1) "diff -up"
-
+1) ``diff -up``
+---
 
-If you must generate your patches by hand, use "diff -up" or "diff -uprN"
+If you must generate your patches by hand, 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
-in "unified diff" format, as supplied by the '-u' argument to diff(1).
-Also, please use the '-p' argument which shows which C function each
+in "unified diff" format, as supplied by the ``-u`` argument to diff(1).
+Also, please use the ``-p`` argument which shows which C function each
 change is in - that makes the resultant diff a lot easier to read.
 Patches should be based in the root kernel source directory,
 not in any lower subdirectory.
 
-To create a patch for a single file, it is often sufficient to do:
+To create a patch for a single file, it is often sufficient to do::
 
SRCTREE= linux
MYFILE=  drivers/net/mydriver.c
@@ -75,7 +71,7 @@ To create a patch for a single file, it is often sufficient 
to do:
 
 To create a patch for multiple files, you should unpack a "vanilla",
 or unmodified kernel source tree, and generate a diff against your
-own source tree.  For example:
+own source tree.  For example::
 
MYSRC= /devel/linux
 
@@ -84,7 +80,7 @@ own source tree.  For example:
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
linux-3.19-vanilla $MYSRC > /tmp/patch
 
-"dontdiff" is a list of files which are generated by the kernel during
+``dontdiff`` is a list of files which are generated by the kernel during
 the build process, and should be ignored in any diff(1)-generated
 patch.
 
@@ -93,18 +89,18 @@ belong in a patch submission.  Make sure to review your 
patch -after-
 generating it with diff(1), to ensure accuracy.
 
 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 review by other kernel developers,
+individual patches which modify things in logical stages; see
+:ref:`split_changes`.  This will facilitate review 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
+If you're using git, ``git rebase -i`` can help you 

[PATCH v4 19/29] Documentation/SubmittingPatches: convert it to ReST markup

[Mauro Carvalho Chehab]

- Change the sections to use ReST markup;
- Add cross-references where needed;
- convert aspas to verbatim text;
- use code block tags;
- make Sphinx happy.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmittingPatches | 207 
 1 file changed, 105 insertions(+), 102 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8c79f1d53731..04a4284d8ee4 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -1,9 +1,6 @@
 
-   How to Get Your Change Into the Linux Kernel
-   or
-   Care And Operation Of Your Linus Torvalds
-
-
+How to Get Your Change Into the Linux Kernel or Care And Operation Of Your 
Linus Torvalds
+=
 
 For a person or company who wishes to submit a change to the Linux
 kernel, the process can sometimes be daunting if you're not familiar
@@ -24,9 +21,8 @@ of the mechanical work done for you, though you'll still need 
to prepare
 and document a sensible set of patches.  In general, use of git will make
 your life as a kernel developer easier.
 
-
-SECTION 1 - CREATING AND SENDING YOUR CHANGE
-
+Creating and Sending your Change
+
 
 
 0) Obtain a current source tree
@@ -34,35 +30,35 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
 
 If you do not have a repository with the current kernel source handy, use
 git to obtain one.  You'll want to start with the mainline repository,
-which can be grabbed with:
+which can be grabbed with::
 
-  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
+  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 Note, however, that you may not want to develop against the mainline tree
 directly.  Most subsystem maintainers run their own trees and want to see
-patches prepared against those trees.  See the "T:" entry for the subsystem
+patches prepared against those trees.  See the **T:** entry for the subsystem
 in the MAINTAINERS file to find that tree, or simply ask the maintainer if
 the tree is not listed there.
 
 It is still possible to download kernel releases via tarballs (as described
 in the next section), but that is the hard way to do kernel development.
 
-1) "diff -up"
-
+1) ``diff -up``
+---
 
-If you must generate your patches by hand, use "diff -up" or "diff -uprN"
+If you must generate your patches by hand, 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
-in "unified diff" format, as supplied by the '-u' argument to diff(1).
-Also, please use the '-p' argument which shows which C function each
+in "unified diff" format, as supplied by the ``-u`` argument to diff(1).
+Also, please use the ``-p`` argument which shows which C function each
 change is in - that makes the resultant diff a lot easier to read.
 Patches should be based in the root kernel source directory,
 not in any lower subdirectory.
 
-To create a patch for a single file, it is often sufficient to do:
+To create a patch for a single file, it is often sufficient to do::
 
SRCTREE= linux
MYFILE=  drivers/net/mydriver.c
@@ -75,7 +71,7 @@ To create a patch for a single file, it is often sufficient 
to do:
 
 To create a patch for multiple files, you should unpack a "vanilla",
 or unmodified kernel source tree, and generate a diff against your
-own source tree.  For example:
+own source tree.  For example::
 
MYSRC= /devel/linux
 
@@ -84,7 +80,7 @@ own source tree.  For example:
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
linux-3.19-vanilla $MYSRC > /tmp/patch
 
-"dontdiff" is a list of files which are generated by the kernel during
+``dontdiff`` is a list of files which are generated by the kernel during
 the build process, and should be ignored in any diff(1)-generated
 patch.
 
@@ -93,18 +89,18 @@ belong in a patch submission.  Make sure to review your 
patch -after-
 generating it with diff(1), to ensure accuracy.
 
 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 review by other kernel developers,
+individual patches which modify things in logical stages; see
+:ref:`split_changes`.  This will facilitate review 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
+If you're using git, ``git rebase -i`` can help you with this process.  If