Fixed docs typos in lines ending with a dash.
This commit is contained in:
parent
5d35181de4
commit
e261337eea
|
@ -109,9 +109,9 @@ Committing guidelines
|
|||
In addition, please follow the following guidelines when committing code to
|
||||
Django's Git repository:
|
||||
|
||||
* Never change the published history of django/django branches! **Never force-
|
||||
push your changes to django/django.** If you absolutely must (for security
|
||||
reasons for example) first discuss the situation with the core team.
|
||||
* Never change the published history of django/django branches! **Never
|
||||
force-push your changes to django/django.** If you absolutely must (for
|
||||
security reasons for example) first discuss the situation with the core team.
|
||||
|
||||
* For any medium-to-big changes, where "medium-to-big" is according to
|
||||
your judgment, please bring things up on the |django-developers|
|
||||
|
|
|
@ -179,8 +179,8 @@ commit, for example to fix a typo in a docstring::
|
|||
# The second and third commits should be applied.
|
||||
|
||||
If your topic branch is already published at GitHub, for example if you're
|
||||
making minor changes to take into account a review, you will need to force-
|
||||
push the changes::
|
||||
making minor changes to take into account a review, you will need to force-push
|
||||
the changes::
|
||||
|
||||
git push -f origin ticket_xxxxx
|
||||
|
||||
|
|
|
@ -340,8 +340,8 @@ Application registry
|
|||
|
||||
Returns the :class:`~django.db.models.Model` with the given ``app_label``
|
||||
and ``model_name``. As a shortcut, this method also accepts a single
|
||||
argument in the form ``app_label.model_name``. ``model_name`` is case-
|
||||
insensitive.
|
||||
argument in the form ``app_label.model_name``. ``model_name`` is
|
||||
case-insensitive.
|
||||
|
||||
Raises :exc:`LookupError` if no such application or model exists. Raises
|
||||
:exc:`ValueError` when called with a single argument that doesn't contain
|
||||
|
|
|
@ -1035,8 +1035,8 @@ with the following notable differences:
|
|||
:class:`StreamingHttpResponse` should only be used in situations where it is
|
||||
absolutely required that the whole content isn't iterated before transferring
|
||||
the data to the client. Because the content can't be accessed, many
|
||||
middlewares can't function normally. For example the ``ETag`` and ``Content-
|
||||
Length`` headers can't be generated for streaming responses.
|
||||
middlewares can't function normally. For example the ``ETag`` and
|
||||
``Content-Length`` headers can't be generated for streaming responses.
|
||||
|
||||
Attributes
|
||||
----------
|
||||
|
|
|
@ -21,8 +21,8 @@ handling date/times. When enabled, this Django will store date/times in UTC,
|
|||
use timezone-aware objects internally, and translate them to users' local
|
||||
timezones for display.
|
||||
|
||||
If you're upgrading an existing project to Django 1.4, switching to the time-
|
||||
zone aware mode may take some care: the new mode disallows some rather sloppy
|
||||
If you're upgrading an existing project to Django 1.4, switching to the timezone
|
||||
aware mode may take some care: the new mode disallows some rather sloppy
|
||||
behavior that used to be accepted. We encourage anyone who's upgrading to check
|
||||
out the :ref:`timezone migration guide <time-zones-migration-guide>` and the
|
||||
:ref:`timezone FAQ <time-zones-faq>` for useful pointers.
|
||||
|
|
Loading…
Reference in New Issue