diff --git a/Documenation/SubmittingPatches.md b/Documenation/SubmittingPatches.md
index 1acca0396..92b5fcb48 100644
--- a/Documenation/SubmittingPatches.md
+++ b/Documenation/SubmittingPatches.md
@@ -4,27 +4,6 @@ to this repository.
 Make separate commits for logically separate changes.
 =====================================================
 
-Give an explanation for the change(s) that is detailed enough so
-that people can judge if it is good thing to do, without reading
-the actual patch text to determine how well the code does what
-the explanation promises to do.
-
-If your description starts to get too long, that's a sign that you
-probably need to split up your commit to finer grained pieces.
-That being said, patches which plainly describe the things that
-help reviewers check the patch, and future maintainers understand
-the code, are the most beautiful patches.  Descriptions that summarise
-the point in the subject well, and describe the motivation for the
-change, the approach taken by the change, and if relevant how this
-differs substantially from the prior version, are all good things
-to have.
-
-Oh, another thing.  We are picky about whitespaces.  Make sure your
-changes do not trigger errors with the sample pre-commit hook shipped
-in templates/hooks--pre-commit.  To help ensure this does not happen,
-run git diff --check on your changes before you commit.
-
-
 Describe your changes well.
 ===========================
 
@@ -71,6 +50,20 @@ with the subject enclosed in a pair of double-quotes, like this:
 The "Copy commit summary" command of gitk can be used to obtain this
 format.
 
+If your description starts to get too long, that's a sign that you
+probably need to split up your commit to finer grained pieces.
+That being said, patches which plainly describe the things that
+help reviewers check the patch, and future maintainers understand
+the code, are the most beautiful patches.  Descriptions that summarise
+the point in the subject well, and describe the motivation for the
+change, the approach taken by the change, and if relevant how this
+differs substantially from the prior version, are all good things
+to have.
+
+Oh, another thing.  We are picky about whitespaces.  Make sure your
+changes do not trigger errors with the sample pre-commit hook shipped
+in templates/hooks--pre-commit.  To help ensure this does not happen,
+run git diff --check on your changes before you commit.
 
 Publish your work in a separate branch.
 =======================================
@@ -87,3 +80,8 @@ Creating a merge/pull request
 
 You often want to add additional explanation about the patch,
 other than the commit message itself.
+
+Give an explanation for the change(s) that is detailed enough so
+that people can judge if it is good thing to do, without reading
+the actual patch text to determine how well the code does what
+the explanation promises to do.