-Describe the technical detail of the change(s).
-
-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.
-
-Oh, another thing. I am 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.
-
-
-(1a) Try to be nice to older C compilers
-
-We try to support a wide range of C compilers to compile
-git with. That means that you should not use C99 initializers, even
-if a lot of compilers grok it.
-
-Also, variables have to be declared at the beginning of the block
-(you can check this with gcc, using the -Wdeclaration-after-statement
-option).
-
-Another thing: NULL pointers shall be written as NULL, not as 0.
-
-
-(2) Generate your patch using git tools out of your commits.
-
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
-
-You do not have to be afraid to use -M option to "git diff" or
-"git format-patch", if your patch involves file renames. The
-receiving end can handle them just fine.
-
-Please 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 generating it, to ensure accuracy. Before
-sending out, please make sure it cleanly applies to the "master"
-branch head. If you are preparing a work based on "next" branch,
-that is fine, but please mark it as such.
-
-
-(3) Sending your patches.
-
-People on the git mailing list need to be able to read and
-comment on the changes you are submitting. It is important for
-a developer to be able to "quote" your changes, using standard
-e-mail tools, so that they may comment on specific portions of
-your code. For this reason, all patches should be submitted
-"inline". WARNING: Be wary of your MUAs word-wrap
-corrupting your patch. Do not cut-n-paste your patch; you can
-lose tabs that way if you are not careful.
-
-It is a common convention to prefix your subject line with
-[PATCH]. This lets people easily distinguish patches from other
-e-mail discussions. Use of additional markers after PATCH and
-the closing bracket to mark the nature of the patch is also
-encouraged. E.g. [PATCH/RFC] is often used when the patch is
-not ready to be applied but it is for discussion, [PATCH v2],
-[PATCH v3] etc. are often seen when you are sending an update to
-what you have previously sent.
-
-"git format-patch" command follows the best current practice to
-format the body of an e-mail message. At the beginning of the
-patch should come your commit message, ending with the
-Signed-off-by: lines, and a line that consists of three dashes,
-followed by the diffstat information and the patch itself. If
-you are forwarding a patch from somebody else, optionally, at
-the beginning of the e-mail message just before the commit
-message starts, you can put a "From: " line to name that person.
-
-You often want to add additional explanation about the patch,
-other than the commit message itself. Place such "cover letter"
-material between the three dash lines and the diffstat.
-
-Do not attach the patch as a MIME attachment, compressed or not.
-Do not let your e-mail client send quoted-printable. Do not let
-your e-mail client send format=flowed which would destroy
-whitespaces in your patches. Many
-popular e-mail applications will not always transmit a MIME
-attachment as plain text, making it impossible to comment on
-your code. A MIME attachment also takes a bit more time to
-process. This does not decrease the likelihood of your
-MIME-attached change being accepted, but it makes it more likely
-that it will be postponed.
-
-Exception: If your mailer is mangling patches then someone may ask
-you to re-send them using MIME, that is OK.
-
-Do not PGP sign your patch, at least for now. Most likely, your
-maintainer or other people on the list would not have your PGP
-key and would not bother obtaining it anyway. Your patch is not
-judged by who you are; a good patch from an unknown origin has a
-far better chance of being accepted than a patch from a known,
-respected origin that is done poorly or does incorrect things.
-
-If you really really really really want to do a PGP signed
-patch, format it as "multipart/signed", not a text/plain message
-that starts with '-----BEGIN PGP SIGNED MESSAGE-----'. That is
-not a text/plain, it's something else.
-
-Note that your maintainer does not necessarily read everything
-on the git mailing list. If your patch is for discussion first,
-send it "To:" the mailing list, and optionally "cc:" him. If it
-is trivially correct or after the list reached a consensus, send
-it "To:" the maintainer and optionally "cc:" the list for
-inclusion.
-
-Also note that your maintainer does not actively involve himself in
-maintaining what are in contrib/ hierarchy. When you send fixes and
-enhancements to them, do not forget to "cc: " the person who primarily
-worked on that hierarchy in contrib/.
-
-
-(4) Sign your work
-
-To improve tracking of who did what, we've borrowed the
-"sign-off" procedure from the Linux kernel project on patches
-that are being emailed around. Although core GIT is a lot
-smaller project it is a good discipline to follow it.
-
-The sign-off is a simple line at the end of the explanation for
-the patch, which certifies that you wrote it or otherwise have
-the right to pass it on as a open-source patch. The rules are
-pretty simple: if you can certify the below:
+1. Make separate commits for logically separate changes.
+
+ Unless your patch is really trivial, you should not be sending out
+ a patch that was generated between your working tree and your
+ commit head. Instead, always make a commit with complete commit
+ message and generate a series of patches from your repository. It
+ is a good discipline.
+
+ Describe the technical detail of the change(s).
+
+ 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.
+
+ Oh, another thing. I am picky about whitespaces. Please run git
+ diff --check on your changes before you commit.
+
+
+2. Generate your patch using Git tools out of your commits.
+
+ Git based diff tools (Git, Cogito, and StGit included) generate
+ unidiff which is the preferred format.
+
+ You do not have to be afraid to use -M option to "git diff" and
+ friends, if your patch involves file renames. The receiving end can
+ handle them just fine.
+
+ Please 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 generating it, to ensure accuracy. Before sending out, please
+ make sure it cleanly applies to the "master" branch head. If you
+ are preparing a work based on some other branch, that is fine, but
+ please mark it as such.
+
+
+3. Sending your patches.
+
+ StGit patches should be sent to the Git mailing list
+ (git@vger.kernel.org), and preferably CCed to the StGit maintainer
+ (catalin.marinas@gmail.com). The recipients need to be able to read
+ and comment on the changes you are submitting. It is important for
+ a developer to be able to "quote" your changes, using standard
+ e-mail tools, so that they may comment on specific portions of your
+ code. For this reason, all patches should be submitted "inline".
+ WARNING: Be wary of your MUAs word-wrap corrupting your patch. Do
+ not cut-n-paste your patch; you can lose tabs that way if you are
+ not careful.
+
+ It is a common convention to prefix your subject line with [StGit
+ PATCH]. This lets people easily distinguish patches to StGit from
+ other e-mail discussions and patches meant for Git itself. Use of
+ additional markers after PATCH and the closing bracket to mark the
+ nature of the patch is also encouraged. E.g. [PATCH/RFC] is often
+ used when the patch is not ready to be applied but it is for
+ discussion, [PATCH v2], [PATCH v3] etc. are often seen when you are
+ sending an update to what you have previously sent.
+
+ "stg mail" command follows the best current practice to format the
+ body of an e-mail message. At the beginning of the patch should
+ come your commit message, ending with the Signed-off-by: lines, and
+ a line that consists of three dashes, followed by the diffstat
+ information and the patch itself. If you are forwarding a patch
+ from somebody else, optionally, at the beginning of the e-mail
+ message just before the commit message starts, you can put a
+ "From:" line to name that person.
+
+ You often want to add additional explanation about the patch, other
+ than the commit message itself. Place such "cover letter" material
+ between the three dash lines and the diffstat. If you have comments
+ about a whole series of patches, you can include them in a separate
+ cover mail message (the -e option to stg mail).
+
+ Do not attach the patch as a MIME attachment, compressed or not. Do
+ not let your e-mail client send quoted-printable. Do not let your
+ e-mail client send format=flowed which would destroy whitespaces in
+ your patches. Many popular e-mail applications will not always
+ transmit a MIME attachment as plain text, making it impossible to
+ comment on your code. A MIME attachment also takes a bit more time
+ to process. This does not decrease the likelihood of your
+ MIME-attached change being accepted, but it makes it more likely
+ that it will be postponed.
+
+ Exception: If your mailer is mangling patches then someone may ask
+ you to re-send them using MIME, that is OK.
+
+ Do not PGP sign your patch, at least for now. Most likely, your
+ maintainer or other people on the list would not have your PGP key
+ and would not bother obtaining it anyway. Your patch is not judged
+ by who you are; a good patch from an unknown origin has a far
+ better chance of being accepted than a patch from a known,
+ respected origin that is done poorly or does incorrect things.
+
+
+4. Sign your work
+
+ To improve tracking of who did what, we've borrowed the "sign-off"
+ procedure from the Git and Linux kernel projects on patches that
+ are being emailed around. Although StGit is a lot smaller project
+ it is a good discipline to follow it.
+
+ The sign-off is a simple line at the end of the explanation for the
+ patch, which certifies that you wrote it or otherwise have the
+ right to pass it on as a open-source patch. The rules are pretty
+ simple: if you can certify the below:
~mdw / stgit / blobdiff