Replaced "django" with "Django" in spelling_wordlist.

This commit is contained in:
akki 2016-11-16 03:30:50 +05:30 committed by Tim Graham
parent 7c6efb3233
commit 74ed20b49a
21 changed files with 62 additions and 66 deletions

View file

@ -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 by force
pushing. If you absolutely must (for security reasons for example), first
discuss the situation with the team.
* For any medium-to-big changes, where "medium-to-big" is according to
your judgment, please bring things up on the |django-developers|
@ -242,7 +242,7 @@ When a mistaken commit is discovered, please follow these guidelines:
* The release branch maintainer may back out commits to the release
branch without permission if the commit breaks the release branch.
* If you mistakenly push a topic branch to django/django, just delete it.
* If you mistakenly push a topic branch to ``django/django``, just delete it.
For instance, if you did: ``git push upstream feature_antigravity``,
just do a reverse push: ``git push upstream :feature_antigravity``.

View file

@ -145,8 +145,8 @@ FAQ
First off, it's not personal. Django is entirely developed by volunteers
(even the core team), and sometimes folks just don't have time. The best
thing to do is to send a gentle reminder to the |django-developers| mailing
list asking for review on the ticket, or to bring it up in the #django-dev
IRC channel.
list asking for review on the ticket, or to bring it up in the
`#django-dev` IRC channel.
2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
myself?**

View file

@ -55,8 +55,8 @@ cloned directory, so switch to it now::
Your GitHub repository will be called "origin" in Git.
You should also setup django/django as an "upstream" remote (that is, tell git
that the reference Django repository was the source of your fork of it)::
You should also setup ``django/django`` as an "upstream" remote (that is, tell
git that the reference Django repository was the source of your fork of it)::
git remote add upstream git@github.com:django/django.git
git fetch upstream
@ -116,7 +116,7 @@ their clone would become corrupt when you edit commits.
There are also "public branches". These are branches other people are supposed
to fork, so the history of these branches should never change. Good examples
of public branches are the ``master`` and ``stable/A.B.x`` branches in the
django/django repository.
``django/django`` repository.
When you think your work is ready to be pulled into Django, you should create
a pull request at GitHub. A good pull request means:
@ -193,14 +193,14 @@ a topic branch, and nobody should be basing their work on it.
After upstream has changed
--------------------------
When upstream (django/django) has changed, you should rebase your work. To
When upstream (``django/django``) has changed, you should rebase your work. To
do this, use::
git fetch upstream
git rebase
The work is automatically rebased using the branch you forked on, in the
example case using upstream/master.
example case using ``upstream/master``.
The rebase command removes all your local commits temporarily, applies the
upstream commits, and then applies your local commits again on the work.