Made minor edits and corrections to docs/internals/git.txt.

docs/internals/git.txt

@@ -101,14 +101,14 @@ For example, immediately after *Django 1.5 alpha 1* was tagged, the branch
 ``stable/1.5.x`` was created and all further work on preparing the code for the
 final 1.5 release was done there.
 
-These branches also provide limited bugfix support for the most recent released
-version of Django and security support for the two most recently-released
-versions of Django.
+These branches also provide bugfix and security support as described in
+:ref:`supported-versions-policy`.
 
 For example, after the release of Django 1.5, the branch ``stable/1.5.x``
 receives only fixes for security and critical stability bugs, which are
 eventually released as Django 1.5.1 and so on, ``stable/1.4.x`` receives only
-security fixes, and ``stable/1.3.x`` no longer receives any updates.
+security and data loss fixes, and ``stable/1.3.x`` no longer receives any
+updates.
 
 .. admonition:: Historical information
 
@@ -117,13 +117,13 @@ security fixes, and ``stable/1.3.x`` no longer receives any updates.
 
     Previously, these branches weren't created until right after the releases
     and the stabilization work occurred on the main repository branch. Thus,
-    no new features development work for the next release of Django could be
+    no new feature development work for the next release of Django could be
     committed until the final release happened.
 
     For example, shortly after the release of Django 1.3 the branch
     ``stable/1.3.x`` was created. Official support for that release has expired,
     and so it no longer receives direct maintenance from the Django project.
-    However, that and all other similarly named branches continue to exist and
+    However, that and all other similarly named branches continue to exist, and
     interested community members have occasionally used them to provide
     unofficial support for old Django releases.
 
@@ -142,7 +142,7 @@ Feature-development branches
 
 Feature-development branches tend by their nature to be temporary. Some
 produce successful features which are merged back into Django's master to
-become part of an official release, but others do not; in either case there
+become part of an official release, but others do not; in either case, there
 comes a time when the branch is no longer being actively worked on by any
 developer. At this point the branch is considered closed.
 
@@ -192,9 +192,9 @@ part of Django itself, and so are no longer separately maintained:
   Unicode-based strings in most places within Django and Django
   applications. This became part of Django as of the 1.0 release.
 
-When Django moved from SVN to Git, the information about branch merges wasn't
-preserved in the source code repository. This means that the ``master`` branch
-of Django doesn't contain merge commits for the above branches.
+When Django moved from Subversion to Git, the information about branch merges
+wasn't preserved in the source code repository. This means that the ``master``
+branch of Django doesn't contain merge commits for the above branches.
 
 However, this information is `available as a grafts file`_. You can restore it
 by putting the following lines in ``.git/info/grafts`` in your local clone::
@@ -237,7 +237,7 @@ were never finished:
 All of the above-mentioned branches now reside in ``attic``.
 
 Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature
-branches, used for Google Summer of Code projects.
+branches, used for the 2009 and 2010 Google Summer of Code projects.
 
 Tags
 ====