diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index 0877511dc8..32be5f1f06 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -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| diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 00f9b79c09..d2e45ad829 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -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 diff --git a/docs/ref/applications.txt b/docs/ref/applications.txt index 0811bdf75f..c289afcef9 100644 --- a/docs/ref/applications.txt +++ b/docs/ref/applications.txt @@ -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 diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt index 531b1c872c..b344158d57 100644 --- a/docs/ref/request-response.txt +++ b/docs/ref/request-response.txt @@ -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 ---------- diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 2e1149992c..fa5f04d151 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -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 ` and the :ref:`timezone FAQ ` for useful pointers.