Skip to content

Commit

Permalink
Documentation: Move paragraphs to better places
Browse files Browse the repository at this point in the history
These paragraphs talk about descriptive text not about commit
separation.
  • Loading branch information
donald committed Nov 23, 2016
1 parent 9c70490 commit 0fc13f2
Showing 1 changed file with 19 additions and 21 deletions.
40 changes: 19 additions & 21 deletions Documenation/SubmittingPatches.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
===========================

Expand Down Expand Up @@ -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.
=======================================
Expand All @@ -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.

0 comments on commit 0fc13f2

Please sign in to comment.