Change tabs to spaces.

diff --git a/www/git.xhtml b/www/git.xhtml
index f509257f02254ecf7f2dccdbe950cd2e2b509792..2fc8a8a41463c38624d8a95a0126ffd1c5722a0e 100644 (file)
--- a/www/git.xhtml
+++ b/www/git.xhtml
@@ -75,48 +75,48 @@ git clone ssh://git@git.i-scream.org/libstatgrab
           <p>
             <a href="http://github.com/i-scream">http://github.com/i-scream</a>
           </p>
-         <h3>
-           Git guidelines
-         </h3>
-         <p>
-           We've chosen a set of guidelines to work by so that
-           everybody is clear about how the Git repositories will be
-           used. This should make life easier for developers and
-           users. The aim is to keep things clear and simple without
-           adding unnecessary overheads. We don't have need for
-           anything as complex as git-flow.
-         </p>
-         <ol>
-           <li>
-             The <code>master</code> branch will always be buildable
-             and should be usable. Development work does not happen
-             here directly.
-           </li>
-           <li>
-             New releases will be taken from the <code>master</code>
-             branch and will be tagged there.
-           </li>
-           <li>
-             The master branch will never have its history rewritten.
-           </li>
-           <li>
-             Development work will be done on branches. These
-             branches may only live for the period of the development
-             work. Once the work is complete and tested it will be
-             merged to master and the branch may be deleted.
-           </li>
-           <li>
-             The history on development branches may be rewritten to
-             tidy things up before merging. This probably won't
-             happen often, but don't get upset if it does.
-           </li>
-           <li>
-             If you want to submit changes it's best to do them
-             against the <code>master</code> branch unless you're
-             specifically working with a developer on an issue
-             already.
-           </li>
-         </ol>
+          <h3>
+            Git guidelines
+          </h3>
+          <p>
+            We've chosen a set of guidelines to work by so that
+            everybody is clear about how the Git repositories will be
+            used. This should make life easier for developers and
+            users. The aim is to keep things clear and simple without
+            adding unnecessary overheads. We don't have need for
+            anything as complex as git-flow.
+          </p>
+          <ol>
+            <li>
+              The <code>master</code> branch will always be buildable
+              and should be usable. Development work does not happen
+              here directly.
+            </li>
+            <li>
+              New releases will be taken from the <code>master</code>
+              branch and will be tagged there.
+            </li>
+            <li>
+              The master branch will never have its history rewritten.
+            </li>
+            <li>
+              Development work will be done on branches. These
+              branches may only live for the period of the development
+              work. Once the work is complete and tested it will be
+              merged to master and the branch may be deleted.
+            </li>
+            <li>
+              The history on development branches may be rewritten to
+              tidy things up before merging. This probably won't
+              happen often, but don't get upset if it does.
+            </li>
+            <li>
+              If you want to submit changes it's best to do them
+              against the <code>master</code> branch unless you're
+              specifically working with a developer on an issue
+              already.
+            </li>
+          </ol>
         </div>
 <!--#include virtual="/footer.inc" -->
       </div>