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

This commit is contained in:
Chris Hasbrouck 2018-01-31 10:04:19 -08:00 committed by Tim Graham
parent 4fe0e619e7
commit 92fe161e69
1 changed files with 11 additions and 11 deletions

View File

@ -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 ``stable/1.5.x`` was created and all further work on preparing the code for the
final 1.5 release was done there. final 1.5 release was done there.
These branches also provide limited bugfix support for the most recent released These branches also provide bugfix and security support as described in
version of Django and security support for the two most recently-released :ref:`supported-versions-policy`.
versions of Django.
For example, after the release of Django 1.5, the branch ``stable/1.5.x`` 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 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 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 .. 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 Previously, these branches weren't created until right after the releases
and the stabilization work occurred on the main repository branch. Thus, 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. committed until the final release happened.
For example, shortly after the release of Django 1.3 the branch 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, ``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. 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 interested community members have occasionally used them to provide
unofficial support for old Django releases. unofficial support for old Django releases.
@ -142,7 +142,7 @@ Feature-development branches
Feature-development branches tend by their nature to be temporary. Some Feature-development branches tend by their nature to be temporary. Some
produce successful features which are merged back into Django's master to 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 comes a time when the branch is no longer being actively worked on by any
developer. At this point the branch is considered closed. 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 Unicode-based strings in most places within Django and Django
applications. This became part of Django as of the 1.0 release. 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 When Django moved from Subversion to Git, the information about branch merges
preserved in the source code repository. This means that the ``master`` branch wasn't preserved in the source code repository. This means that the ``master``
of Django doesn't contain merge commits for the above branches. 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 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:: 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``. All of the above-mentioned branches now reside in ``attic``.
Finally, the repository contains ``soc2009/xxx`` and ``soc2010/xxx`` feature 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 Tags
==== ====