Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Rename default branch to ‘main’. 

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg 2021-08-31 15:15:31 -07:00 committed by Anders Kaseorg
parent 1c3517a5de
commit 646c04eff2
60 changed files with 218 additions and 218 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -8,8 +8,8 @@ allows users to easily process hundreds or thousands of messages a day. With
over 700 contributors merging over 500 commits a month, Zulip is also the
largest and fastest growing open source group chat project.
[![GitHub Actions build status](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml/badge.svg?branch=master)](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml?query=branch%3Amaster)
[![coverage status](https://img.shields.io/codecov/c/github/zulip/zulip/master.svg)](https://codecov.io/gh/zulip/zulip/branch/master)
[![GitHub Actions build status](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml/badge.svg)](https://github.com/zulip/zulip/actions/workflows/zulip-ci.yml?query=branch%3Amain)
[![coverage status](https://img.shields.io/codecov/c/github/zulip/zulip/main.svg)](https://codecov.io/gh/zulip/zulip)
[![Mypy coverage](https://img.shields.io/badge/mypy-100%25-green.svg)][mypy-coverage]
[![code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
[![code style: prettier](https://img.shields.io/badge/code_style-prettier-ff69b4.svg)](https://github.com/prettier/prettier)
@ -75,6 +75,6 @@ You might be interested in:
You may also be interested in reading our [blog](https://blog.zulip.org/) or
following us on [Twitter](https://twitter.com/zulip).
Zulip is distributed under the
[Apache 2.0](https://github.com/zulip/zulip/blob/master/LICENSE) license.
[Apache 2.0](https://github.com/zulip/zulip/blob/main/LICENSE) license.
[beginner-friendly]: https://github.com/zulip/zulip/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22

4
docs/contributing/code-reviewing.md
View File

@ -28,7 +28,7 @@ to dive right into reviewing the PR's core functionality.
Once you've received a review and resolved any feedback, it's critical
to update the GitHub thread to reflect that. Best practices are to:
* Make sure that CI passes and the PR is rebased onto recent master.
* Make sure that CI passes and the PR is rebased onto recent main.
* Post comments on each feedback thread explaining at least how you
resolved the feedback, as well as any other useful information
(problems encountered, reasoning for why you picked one of several
@ -215,7 +215,7 @@ Some points specific to the Zulip server codebase:
To make it easier to review pull requests, if you're working in the
Zulip server codebase, use our [git tool]
`tools/fetch-rebase-pull-request` to check out a pull request locally
and rebase it against master.
and rebase it against main.
If a pull request just needs a little fixing to make it mergeable,
feel free to do that in a new commit, then push your branch to GitHub

2
docs/development/setup-vagrant.md
View File

@ -445,7 +445,7 @@ guide][rtd-git-guide].
If after rebasing onto a new version of the Zulip server, you receive
new errors while starting the Zulip server or running tests, this is
probably not because Zulip's master branch is broken. Instead, this
probably not because Zulip's main branch is broken. Instead, this
is likely because we've recently merged changes to the development
environment provisioning process that you need to apply to your
development environment. To update your environment, you'll need to

2
docs/development/test-install.md
View File

@ -6,7 +6,7 @@ configurations; when making changes to more complicated [installation
options][installer-docs], Zulip provides tooling to repeatedly test
the installation process in a clean environment each time.
[CI]: https://github.com/zulip/zulip/actions/workflows/production-suite.yml?query=branch%3Amaster
[CI]: https://github.com/zulip/zulip/actions/workflows/production-suite.yml?query=branch%3Amain
[installer-docs]: ../production/install.md
## Configuring

4
docs/development/using.md
View File

@ -13,9 +13,9 @@ the development environment][authentication-dev-server].
## Common
* Zulip's master branch moves quickly, and you should rebase
* Zulip's main branch moves quickly, and you should rebase
constantly with e.g. `git fetch upstream; git rebase
upstream/master` to avoid developing on an old version of the Zulip
upstream/main` to avoid developing on an old version of the Zulip
codebase (leading to unnecessary merge conflicts).
* Remember to run `tools/provision` to update your development
environment after switching branches; it will run in under a second

2
docs/documentation/integrations.md
View File

@ -146,7 +146,7 @@ Here are a few common macros used to document Zulip's integrations:
[github-integration]: https://zulip.com/integrations/doc/github
[codebase]: https://zulip.com/integrations/doc/codebase
[beanstalk]: https://zulip.com/integrations/doc/beanstalk
[integrations-file]: https://github.com/zulip/zulip/blob/master/zerver/lib/integrations.py
[integrations-file]: https://github.com/zulip/zulip/blob/main/zerver/lib/integrations.py
## Writing guidelines

2
docs/documentation/user.md
View File

@ -252,7 +252,7 @@ The tab identifiers (e.g. `desktop-web` above) and their mappings to
the tabs' labels are declared in
[zerver/lib/markdown/tabbed_sections.py][tabbed-sections-code].
[tabbed-sections-code]: https://github.com/zulip/zulip/blob/master/zerver/lib/markdown/tabbed_sections.py
[tabbed-sections-code]: https://github.com/zulip/zulip/blob/main/zerver/lib/markdown/tabbed_sections.py
This widget can also be used just to create a nice box around a set of
instructions

18
docs/git/cheat-sheet.md
View File

@ -8,7 +8,7 @@ See also [fixing commits][fix-commit]
- `git add foo.py`
- checkout
- `git checkout -b new-branch-name`
- `git checkout master`
- `git checkout main`
- `git checkout old-branch-name`
- commit
- `git commit -m "topic: Commit message title."`
@ -36,8 +36,8 @@ See also [fixing commits][fix-commit]
- `git push origin +branch-name`
- rebase
- `git rebase -i HEAD~3`
- `git rebase -i master`
- `git rebase upstream/master`
- `git rebase -i main`
- `git rebase upstream/main`
- reflog
- `git reflog | head -10`
- remote
@ -49,7 +49,7 @@ See also [fixing commits][fix-commit]
- show
- `git show HEAD`
- `git show HEAD~~~`
- `git show master`
- `git show main`
- status
- `git status`
@ -61,7 +61,7 @@ See also [fixing commits][fix-commit]
- `git add -u`: Adds all tracked files to the staging area.
- checkout
- `git checkout -b new-branch-name`: create branch `new-branch-name` and switch to/check out that new branch
- `git checkout master`: switch to your `master` branch
- `git checkout main`: switch to your `main` branch
- `git checkout old-branch-name`: switch to an existing branch `old-branch-name`
- commit
- `git commit -m "commit message"`: It is recommended to type a
@ -84,7 +84,7 @@ See also [fixing commits][fix-commit]
- `git log`: show commit logs
- `git log --oneline | head`: To quickly see the latest ten commits on a branch.
- pull
- `git pull --rebase`: rebase your changes on top of master.
- `git pull --rebase`: rebase your changes on top of main.
- `git pull` (with no options): Will either create a merge commit
(which you don't want) or do the same thing as `git pull --rebase`,
depending on [whether you've configured Git properly][git-config-clone]
@ -94,8 +94,8 @@ See also [fixing commits][fix-commit]
- `git push origin +branch-name`: force push your commits to your origin repository.
- rebase
- `git rebase -i HEAD~3`: interactive rebasing current branch with first three items on HEAD
- `git rebase -i master`: interactive rebasing current branch with master branch
- `git rebase upstream/master`: rebasing current branch with master branch from upstream repository
- `git rebase -i main`: interactive rebasing current branch with main branch
- `git rebase upstream/main`: rebasing current branch with main branch from upstream repository
- reflog
- `git reflog | head -10`: manage reference logs for the past 10 commits
- remote
@ -107,7 +107,7 @@ See also [fixing commits][fix-commit]
- show
- `git show HEAD`: display most recent commit
- `git show HEAD~~~`: display third most recent commit
- `git show master`: display most recent commit on `master`
- `git show main`: display most recent commit on `main`
- status
- `git status`: show the working tree status, unstaged and staged files

8
docs/git/pull-requests.md
View File

@ -26,7 +26,7 @@ work from being merged before you're confident in it.
## Create a pull request
### Step 0: Make sure you're on a feature branch (not `master`)
### Step 0: Make sure you're on a feature branch (not `main`)
It is important to [work on a feature
branch](using.html#work-on-a-feature-branch) when creating a pull
@ -35,7 +35,7 @@ branch while it is open, so you will need to reserve your branch only
for changes related to your issue, and avoid introducing extraneous
changes for other issues or from upstream.
If you are working on a branch named `master`, you need to create and
If you are working on a branch named `main`, you need to create and
switch to a feature branch before proceeding.
### Step 1: Update your branch with git rebase
@ -56,9 +56,9 @@ remote: Compressing objects: 100% (23/23), done.
remote: Total 69 (delta 49), reused 39 (delta 39), pack-reused 7
Unpacking objects: 100% (69/69), done.
From https://github.com/zulip/zulip
69fa600..43e21f6 master -> upstream/master
69fa600..43e21f6 main -> upstream/main
$ git rebase upstream/master
$ git rebase upstream/main
First, rewinding head to replay your work on top of it...
Applying: troubleshooting tip about provisioning

12
docs/git/reviewing.md
View File

@ -43,22 +43,22 @@ $ git diff e2f404c 7977169
## Changes between branches
Display changes between tip of topic branch and tip of master branch:
Display changes between tip of topic branch and tip of main branch:
```console
$ git diff topic master
$ git diff topic main
```
Display changes that have occurred on master branch since topic branch was created:
Display changes that have occurred on main branch since topic branch was created:
```console
$ git diff topic...master
$ git diff topic...main
```
Display changes you've committed so far since creating a branch from upstream/master:
Display changes you've committed so far since creating a branch from upstream/main:
```console
$ git diff upstream/master...HEAD
$ git diff upstream/main...HEAD
```
[zulip-rtd-review]: ../contributing/code-reviewing.md

24
docs/git/troubleshooting.md
View File

@ -27,7 +27,7 @@ You'll know you're creating a merge commit if you're prompted for a commit
message and the default is something like this:
```text
Merge branch 'master' of https://github.com/zulip/zulip
Merge branch 'main' of https://github.com/zulip/zulip
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
@ -44,7 +44,7 @@ Merge: 13bea0e e0c10ed
Author: Christie Koehler <ck@christi3k.net>
Date: Mon Oct 10 13:25:51 2016 -0700
Merge branch 'master' of https://github.com/zulip/zulip
Merge branch 'main' of https://github.com/zulip/zulip
```
Some graphical Git clients may also create merge commits.
@ -55,7 +55,7 @@ to roll back to:
```console
$ git reflog
e5f8211 HEAD@{0}: pull upstream master: Merge made by the 'recursive' strategy.
e5f8211 HEAD@{0}: pull upstream main: Merge made by the 'recursive' strategy.
13bea0e HEAD@{1}: commit: test commit for docs.
```
@ -90,7 +90,7 @@ last commit `13bea0e` before the merge:
$ git reflog
13bea0e HEAD@{2}: reset: moving to HEAD@{1}
e5f8211 HEAD@{3}: pull upstream master: Merge made by the 'recursive' strategy.
e5f8211 HEAD@{3}: pull upstream main: Merge made by the 'recursive' strategy.
13bea0e HEAD@{4}: commit: test commit for docs.
```
@ -115,7 +115,7 @@ For example, let's say you just committed "some work" and your `git log` looks
like this:
```console
* 67aea58 (HEAD -> master) some work
* 67aea58 (HEAD -> main) some work
* 13bea0e test commit for docs.
```
@ -126,7 +126,7 @@ $ git reset --hard 13bea0e
HEAD is now at 13bea0e test commit for docs.
$ git log
* 13bea0e (HEAD -> master) test commit for docs.
* 13bea0e (HEAD -> main) test commit for docs.
```
And then realize you actually needed to keep commit 67aea58. First, use `git
@ -139,7 +139,7 @@ $ git reflog
67aea58 HEAD@{1}: commit: some work
$ git cherry-pick 67aea58
[master 67aea58] some work
[main 67aea58] some work
Date: Thu Oct 13 11:51:19 2016 -0700
1 file changed, 1 insertion(+)
create mode 100644 test4.txt
@ -153,10 +153,10 @@ which ever branch you are rebasing on top of, is to code that has been changed
by those new commits.
For example, while I'm working on a file, another contributor makes a change to
that file, submits a pull request and has their code merged into master.
that file, submits a pull request and has their code merged into main.
Usually this is not a problem, but in this case the other contributor made a
change to a part of the file I also want to change. When I try to bring my
branch up to date with `git fetch` and then `git rebase upstream/master`, I see
branch up to date with `git fetch` and then `git rebase upstream/main`, I see
the following:
```console
@ -177,7 +177,7 @@ To check out the original branch and stop rebasing, run "git rebase --abort".
```
This message tells me that Git was not able to apply my changes to README.md
after bringing in the new commits from upstream/master.
after bringing in the new commits from upstream/main.
Running `git status` also gives me some information:
@ -205,7 +205,7 @@ Tip: You can see recent changes made to a file by running the following
commands:
```bash
git fetch upstream
git log -p upstream/master -- /path/to/file
git log -p upstream/main -- /path/to/file
```
You can use this to compare the changes that you have made to a file with the
ones in upstream, helping you avoid undoing changes from a previous commit when
@ -265,7 +265,7 @@ to update:
$ git checkout <my-branch>
Switched to branch '<my-branch>'
$ git merge origin/master
$ git merge origin/main
```
**If you have already made commits on the second computer that you need to

52
docs/git/using.md
View File

@ -20,7 +20,7 @@ branches, with a star next to the current branch:
```console
$ git branch
* issue-demo
master
main
```
To see even more information about your branches, including remote branches,
@ -29,11 +29,11 @@ use `git branch -vva`:
```console
$ git branch -vva
* issue-123 517468b troubleshooting tip about provisioning
master f0eaee6 [origin/master] bug: Fix traceback in get_missed_message_token_from_address().
remotes/origin/HEAD -> origin/master
main f0eaee6 [origin/main] bug: Fix traceback in get_missed_message_token_from_address().
remotes/origin/HEAD -> origin/main
remotes/origin/issue-1234 4aeccb7 Another test commit, with longer message.
remotes/origin/master f0eaee6 bug: Fix traceback in get_missed_message_token_from_address().
remotes/upstream/master dbeab6a Optimize checks of test database state by moving into Python.
remotes/origin/main f0eaee6 bug: Fix traceback in get_missed_message_token_from_address().
remotes/upstream/main dbeab6a Optimize checks of test database state by moving into Python.
```
You can also configure [Bash][gitbook-other-envs-bash] and
@ -57,37 +57,37 @@ configured in the step above:
$ git fetch upstream
```
Next, check out your `master` branch and [rebase][gitbook-git-rebase] it on top
of `upstream/master`:
Next, check out your `main` branch and [rebase][gitbook-git-rebase] it on top
of `upstream/main`:
```console
$ git checkout master
Switched to branch 'master'
$ git checkout main
Switched to branch 'main'
$ git rebase upstream/master
$ git rebase upstream/main
```
This will rollback any changes you've made to master, update it from
`upstream/master`, and then re-apply your changes. Rebasing keeps the commit
This will rollback any changes you've made to main, update it from
`upstream/main`, and then re-apply your changes. Rebasing keeps the commit
history clean and readable.
When you're ready, [push your changes][github-help-push] to your remote fork.
Make sure you're in branch `master` and then run `git push`:
Make sure you're in branch `main` and then run `git push`:
```console
$ git checkout master
$ git push origin master
$ git checkout main
$ git push origin main
```
You can keep any branch up to date using this method. If you're working on a
feature branch (see next section), which we recommend, you would change the
command slightly, using the name of your `feature-branch` rather than `master`:
command slightly, using the name of your `feature-branch` rather than `main`:
```console
$ git checkout feature-branch
Switched to branch 'feature-branch'
$ git rebase upstream/master
$ git rebase upstream/main
$ git push origin feature-branch
```
@ -99,25 +99,25 @@ feature. Recall from [how Git is different][how-git-is-different] that
**Git is designed for lightweight branching and merging.** You can and should
create as many branches as you'd like.
First, make sure your master branch is up-to-date with Zulip upstream ([see
First, make sure your main branch is up-to-date with Zulip upstream ([see
how][zulip-git-guide-up-to-date]).
Next, from your master branch, create a new tracking branch, providing a
Next, from your main branch, create a new tracking branch, providing a
descriptive name for your feature branch:
```console
$ git checkout master
Switched to branch 'master'
$ git checkout main
Switched to branch 'main'
$ git checkout -b issue-1755-fail2ban
Switched to a new branch 'issue-1755-fail2ban'
```
Alternatively, you can create a new branch explicitly based off
`upstream/master`:
`upstream/main`:
```console
$ git checkout -b issue-1755-fail2ban upstream/master
$ git checkout -b issue-1755-fail2ban upstream/main
Switched to a new branch 'issue-1755-fail2ban'
```
@ -317,7 +317,7 @@ testing in a more production-like environment.
The final paragraph indicates that this commit addresses and fixes issue #1755.
When you submit your pull request, GitHub will detect and link this reference
to the appropriate issue. Once your commit is merged into zulip/master, GitHub
to the appropriate issue. Once your commit is merged into zulip/main, GitHub
will automatically close the referenced issue. See [Closing issues via commit
messages][github-help-closing-issues] for details.
@ -335,7 +335,7 @@ This ensures your work is backed up should something happen to your local
machine and allows others to follow your progress. It also allows you to
[work from multiple computers][self-multiple-computers] without losing work.
Pushing to a feature branch is just like pushing to master:
Pushing to a feature branch is just like pushing to main:
```console
$ git push origin <branch-name>
@ -376,7 +376,7 @@ $ git log --all --graph --oneline --decorate
* 985116b docs: Add graphic client recs to Git Guide.
* 3c40103 docs: Add stubs for remaining Git Guide sections.
* fc2c01e docs: Add git guide quickstart.
| * f0eaee6 (upstream/master) bug: Fix traceback in get_missed_message_token_from_address().
| * f0eaee6 (upstream/main) bug: Fix traceback in get_missed_message_token_from_address().
```
Alternatively, use your graphical client to view the history for your feature branch.

2
docs/git/working-copies.md
View File

@ -31,7 +31,7 @@ Sometimes you want to publish commits. Here are some scenarios:
Finally, the Zulip core team will occasionally want your changes!
- The Zulip core team can accept your changes and add them to
the official repo, usually on the master branch.
the official repo, usually on the main branch.
## Relevant Git commands

26
docs/git/zulip-tools.md
View File

@ -44,13 +44,13 @@ checkout.
current branch using `git reset --hard`. Use with caution.**
First, make sure you are working in a branch you want to move (in this
example, we'll use the local `master` branch). Then run the script
example, we'll use the local `main` branch). Then run the script
with the ID number of the pull request as the first argument.
```console
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git checkout main
Switched to branch 'main'
Your branch is up-to-date with 'origin/main'.
$ ./tools/reset-to-pull-request 1900
+ request_id=1900
@ -70,7 +70,7 @@ HEAD is now at 2bcd1d8 troubleshooting tip about provisioning
`tools/fetch-rebase-pull-request` is a short-cut for [checking out a pull
request locally][zulip-git-guide-fetch-pr] in its own branch and then updating it with any
changes from upstream/master with `git rebase`.
changes from upstream/main with `git rebase`.
Run the script with the ID number of the pull request as the first argument.
@ -84,8 +84,8 @@ remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From https://github.com/zulip/zulip
* branch refs/pull/1913/head -> FETCH_HEAD
+ git checkout upstream/master -b review-1913
Branch review-1913 set up to track remote branch master from upstream.
+ git checkout upstream/main -b review-1913
Branch review-1913 set up to track remote branch main from upstream.
Switched to a new branch 'review-1913'
+ git reset --hard FETCH_HEAD
HEAD is now at 99aa2bf Add provision.py fails issue in common errors
@ -96,7 +96,7 @@ Current branch review-1913 is up to date.
## Fetch a pull request without rebasing
`tools/fetch-pull-request` is a similar to `tools/fetch-rebase-pull-request`, but
it does not rebase the pull request against upstream/master, thereby getting
it does not rebase the pull request against upstream/main, thereby getting
exactly the same repository state as the commit author had.
Run the script with the ID number of the pull request as the first argument.
@ -146,11 +146,11 @@ achieve this by granting other users permission to write to your fork.
`tools/clean-branches` is a shell script that removes branches that are either:
1. Local branches that are ancestors of origin/master.
2. Branches in origin that are ancestors of origin/master and named like `$USER-*`.
1. Local branches that are ancestors of origin/main.
2. Branches in origin that are ancestors of origin/main and named like `$USER-*`.
3. Review branches created by `tools/fetch-rebase-pull-request` and `tools/fetch-pull-request`.
First, make sure you are working in branch `master`. Then run the script without any
First, make sure you are working in branch `main`. Then run the script without any
arguments for default behavior. Since removing review branches can inadvertently remove any
feature branches whose names are like `review-*`, it is not done by default. To
use it, run `tools/clean-branches --reviews`.
@ -164,11 +164,11 @@ Deleting local branch review-original-5156 (was 5a1e982)
If there is a merge conflict on yarn.lock, yarn should be run to
regenerate the file. *Important* don't delete the yarn.lock file. Check out the
latest one from origin/master so that yarn knows the previous asset versions.
latest one from origin/main so that yarn knows the previous asset versions.
Run the following commands
```bash
git checkout origin/master -- yarn.lock
git checkout origin/main -- yarn.lock
yarn install
git add yarn.lock
git rebase --continue

4
docs/overview/changelog.md
View File

@ -470,7 +470,7 @@ log][commit-log] for an up-to-date list of raw changes.
was actually an integration for canarytokens.org).
- Reformatted the frontend codebase using prettier. This change was
included in this maintenance release to ensure backporting patches
from master remains easy.
from main remains easy.
### 3.0 -- July 16, 2020
@ -2315,5 +2315,5 @@ easily read them all when upgrading across multiple releases.
* [Upgrade notes for 1.7.0](#upgrade-notes-for-1-7-0)
[docker-zulip]: https://github.com/zulip/docker-zulip
[commit-log]: https://github.com/zulip/zulip/commits/master
[commit-log]: https://github.com/zulip/zulip/commits/main
[latest-changelog]: https://zulip.readthedocs.io/en/latest/overview/changelog.html

16
docs/overview/release-lifecycle.md
View File

@ -60,25 +60,25 @@ the Zulip server itself (E.g. `https://zulip.example.com/help/`).
Many Zulip servers run versions from Git that have not been published
in a stable release.
* [Zulip Cloud](https://zulip.com) essentially runs the master
branch. It is usually a few days behind master (with some
* [Zulip Cloud](https://zulip.com) essentially runs the main
branch. It is usually a few days behind main (with some
cherry-picked bug fixes), but can fall up to 2 weeks behind when
major UI or internals changes mean we'd like to bake changes longer
on chat.zulip.org before exposing them to the full Zulip Cloud
userbase.
* [chat.zulip.org][chat-zulip-org], the bleeding-edge server for the
Zulip development community, is upgraded to master several times
every week. We also often "test deploy" changes not yet in master
Zulip development community, is upgraded to main several times
every week. We also often "test deploy" changes not yet in main
to chat.zulip.org to facilitate design feedback.
* We maintain Git branches with names like `4.x` containing backported
commits from master that we plan to include in the next maintenance
commits from main that we plan to include in the next maintenance
release. Self hosters can [upgrade][upgrade-from-git] to these
stable release branches to get bug fixes staged for the next stable
release (which is very useful when you reported a bug whose fix we
choose to backport). We support these branches as though they were a
stable release.
* Self-hosters who want new features not yet present in a major
release can [upgrade to master][upgrading-to-master] or run [a fork
release can [upgrade to main][upgrading-to-main] or run [a fork
of Zulip][fork-zulip].
### Compatibility and upgrading
@ -117,7 +117,7 @@ bug fix release, transparently documenting the issue(s) using the
industry-standard [CVE advisory process](https://cve.mitre.org/).
When new security releases are published, we simultaneously publish
the fixes to the `master` and stable release branches (E.g. `4.x`), so
the fixes to the `main` and stable release branches (E.g. `4.x`), so
that anyone using those branches can immediately upgrade as well.
See also our [security model][security-model] documentation.
@ -227,7 +227,7 @@ core community, like the Python and JavaScript bindings, are released
independently as needed.
[electron]: https://www.electronjs.org/
[upgrading-to-master]: ../production/upgrade-or-modify.html#upgrading-to-master
[upgrading-to-main]: ../production/upgrade-or-modify.html#upgrading-to-main
[os-upgrade]: ../production/upgrade-or-modify.html#upgrading-the-operating-system
[chat-zulip-org]: https://zulip.com/developer-community/
[fork-zulip]: ../production/upgrade-or-modify.html#modifying-zulip

2
docs/production/authentication-methods.md
View File

@ -256,7 +256,7 @@ You can look at the [full list of fields][models-py] in the Zulip user
model; search for `class UserProfile`, but the above should cover all
the fields that would be useful to sync from your LDAP databases.
[models-py]: https://github.com/zulip/zulip/blob/master/zerver/models.py
[models-py]: https://github.com/zulip/zulip/blob/main/zerver/models.py
[django-auth-booleans]: https://django-auth-ldap.readthedocs.io/en/latest/users.html#easy-attributes
### Multiple LDAP searches

14
docs/production/deployment.md
View File

@ -21,19 +21,19 @@ and then
[continue the normal installation instructions](../production/install.html#step-2-install-zulip).
You can also [upgrade Zulip from Git](../production/upgrade-or-modify.html#upgrading-from-a-git-repository).
The most common use case for this is upgrading to `master` to get a
The most common use case for this is upgrading to `main` to get a
feature that hasn't made it into an official release yet (often
support for a new base OS release). See [upgrading to
master][upgrade-to-master] for notes on how `master` works and the
main][upgrade-to-main] for notes on how `main` works and the
support story for it, and [upgrading to future
releases][upgrade-to-future-release] for notes on upgrading Zulip
afterwards.
In particular, we are always very glad to investigate problems with
installing Zulip from `master`; they are rare and help us ensure that
installing Zulip from `main`; they are rare and help us ensure that
our next major release has a reliable install experience.
[upgrade-to-master]: ../production/upgrade-or-modify.html#upgrading-to-master
[upgrade-to-main]: ../production/upgrade-or-modify.html#upgrading-to-main
[upgrade-to-future-release]: ../production/upgrade-or-modify.html#upgrading-to-future-releases
## Zulip in Docker
@ -345,9 +345,9 @@ Don't forget to update `server_name`, `ssl_certificate`,
`ssl_certificate_key` and `proxy_pass` with the appropriate values for
your installation.
[nginx-proxy-longpolling-config]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-common/proxy_longpolling
[standalone.pp]: https://github.com/zulip/zulip/blob/master/puppet/zulip/manifests/profile/standalone.pp
[zulipchat-puppet]: https://github.com/zulip/zulip/tree/master/puppet/zulip_ops/manifests
[nginx-proxy-longpolling-config]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-common/proxy_longpolling
[standalone.pp]: https://github.com/zulip/zulip/blob/main/puppet/zulip/manifests/profile/standalone.pp
[zulipchat-puppet]: https://github.com/zulip/zulip/tree/main/puppet/zulip_ops/manifests
### Apache2 configuration

4
docs/production/export-and-import.md
View File

@ -304,11 +304,11 @@ archive of all the organization's uploaded files.
version of Zulip as the server you're exporting from.
* For exports from Zulip Cloud (zulip.com), you need to [upgrade to
master][upgrade-zulip-from-git], since we run run master on
main][upgrade-zulip-from-git], since we run run main on
Zulip Cloud:
```bash
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git master
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git main
```
It is not sufficient to be on the latest stable release, as

2
docs/production/install-existing-server.md
View File

@ -29,7 +29,7 @@ one created by Zulip into it:
```bash
sudo cp /etc/nginx/nginx.conf /etc/nginx.conf.before-zulip-install
sudo curl -fL -o /etc/nginx/nginx.conf.zulip \
https://raw.githubusercontent.com/zulip/zulip/master/puppet/zulip/templates/nginx.conf.template.erb
https://raw.githubusercontent.com/zulip/zulip/main/puppet/zulip/templates/nginx.conf.template.erb
sudo meld /etc/nginx/nginx.conf /etc/nginx/nginx.conf.zulip # be sure to merge to the right
```

2
docs/production/requirements.md
View File

@ -99,7 +99,7 @@ on hardware requirements for larger organizations.
[SSRF]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
[smokescreen-proxy]: ../production/deployment.html#using-an-outgoing-http-proxy
[reverse-proxy]: ../production/deployment.html#putting-the-zulip-application-behind-a-reverse-proxy
[email-mirror-code]: https://github.com/zulip/zulip/blob/master/zerver/management/commands/email_mirror.py
[email-mirror-code]: https://github.com/zulip/zulip/blob/main/zerver/management/commands/email_mirror.py
## Credentials needed

2
docs/production/settings.md
View File

@ -28,7 +28,7 @@ comment documentation for new configuration settings after upgrading
to each new major release.
[update-settings-docs]: ../production/upgrade-or-modify.html#updating-settings-py-inline-documentation
[settings-py-template]: https://github.com/zulip/zulip/blob/master/zproject/prod_settings_template.py
[settings-py-template]: https://github.com/zulip/zulip/blob/main/zproject/prod_settings_template.py
Since Zulip's settings file is a Python script, there are a number of
other things that one can configure that are not documented; ask on

56
docs/production/upgrade-or-modify.md
View File

@ -10,7 +10,7 @@ This page explains how to upgrade, patch, or modify Zulip, including:
- [Upgrading the operating system](#upgrading-the-operating-system)
- [Upgrading PostgreSQL](#upgrading-postgresql)
- [Modifying Zulip](#modifying-zulip)
- [Applying changes from master](#applying-changes-from-master)
- [Applying changes from main](#applying-changes-from-main)
## Upgrading to a release
@ -68,7 +68,7 @@ run into any issues or need to roll back the upgrade.
Zulip supports upgrading a production installation to any commit in a
Git repository, which is great for [running pre-release changes from
master](#applying-changes-from-master) or [maintaining a
main](#applying-changes-from-main) or [maintaining a
fork](#making-changes). The process is simple:
```bash
@ -76,7 +76,7 @@ fork](#making-changes). The process is simple:
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 1.8.1
# Upgrade to a branch (or other Git ref)
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git 2.1.x
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git master
/home/zulip/deployments/current/scripts/upgrade-zulip-from-git main
```
Zulip will automatically fetch the relevant Git commit and upgrade to
@ -87,9 +87,9 @@ containing the changes planned for the next minor release
(E.g. 2.1.5); we support these stable release branches as though they
were a published release.
The `master` branch contains changes planned for the next major
The `main` branch contains changes planned for the next major
release (E.g. 3.0); see our documentation on [running
master](#upgrading-to-master) before upgrading to it.
main](#upgrading-to-main) before upgrading to it.
By default, this uses the main upstream Zulip server repository, but
you can configure any other Git repository by adding a section like
@ -527,8 +527,8 @@ that fact:
are related to the issue, just mention your changes in the issue report.
If you're looking to modify Zulip by applying changes developed by the
Zulip core team and merged into master, skip to [this
section](#applying-changes-from-master).
Zulip core team and merged into main, skip to [this
section](#applying-changes-from-main).
## Making changes
@ -599,9 +599,9 @@ Eventually, you'll want to upgrade to a new Zulip release. If your
changes were integrated into that Zulip release or are otherwise no
longer needed, you can just [upgrade as
usual](#upgrading-to-a-release). If you [upgraded to
master](#upgrading-to-master); review that section again; new
main](#upgrading-to-main); review that section again; new
maintenance releases are likely "older" than your current installation
and you might need to upgrade to the master again rather than to the
and you might need to upgrade to the main again rather than to the
new maintenance release.
Otherwise, you'll need to update your branch by rebasing your changes
@ -640,7 +640,7 @@ different from the above:
[docker-zulip]: https://github.com/zulip/docker-zulip
[docker-zulip-upgrade]: https://github.com/zulip/docker-zulip#upgrading-from-a-git-repository
## Applying changes from master
## Applying changes from main
If you are experiencing an issue that has already been fixed by the
Zulip development community, and you'd like to get the fix now, you
@ -662,7 +662,7 @@ of the change you'd like).
In general, we can't provide unpaid support for issues caused by
cherry-picking arbitrary commits if the issues don't also affect
master or an official release.
main or an official release.
The exception to this rule is when we ask or encourage a user to apply
a change to their production system to help verify the fix resolves
@ -676,14 +676,14 @@ addition to scheduling that change for Zulip's next bug fix release,
we support changes in stable release branches as though they were
released.
### Upgrading to master
### Upgrading to main
Many Zulip servers (including chat.zulip.org and zulip.com) upgrade to
master on a regular basis to get the latest features. Before doing
main on a regular basis to get the latest features. Before doing
so, it's important to understand how to happily run a server based on
master.
main.
For background, it's backporting arbitrary patches from master to an
For background, it's backporting arbitrary patches from main to an
older version requires some care. Common issues include:
* Changes containing database migrations (new files under
@ -698,32 +698,32 @@ unlikely to succeed without help from the core team via a support
contract.
If you need an unreleased feature, the best path is usually to
upgrade to Zulip master using [upgrade-zulip-from-git][]. Before
upgrading to master, make sure you understand:
upgrade to Zulip main using [upgrade-zulip-from-git][]. Before
upgrading to main, make sure you understand:
* In Zulip's version numbering scheme, `master` will always be "newer"
* In Zulip's version numbering scheme, `main` will always be "newer"
than the latest maintenance release (E.g. `3.1` or `2.1.6`) and
"older" than the next major release (E.g. `3.0` or `4.0`).
* The `master` branch is under very active development; dozens of new
changes are integrated into it on most days. The `master` branch
* The `main` branch is under very active development; dozens of new
changes are integrated into it on most days. The `main` branch
can have thousands of changes not present in the latest release (all
of which will be included in our next major release). On average
`master` usually has fewer total bugs than the latest release
`main` usually has fewer total bugs than the latest release
(because we fix hundreds of bugs in every major release) but it
might have some bugs that are more severe than we would consider
acceptable for a release.
* We deploy `master` to chat.zulip.org and zulip.com on a regular
* We deploy `main` to chat.zulip.org and zulip.com on a regular
basis (often daily), so it's very important to the project that it
be stable. Most regressions will be minor UX issues or be fixed
quickly, because we need them to be fixed for Zulip Cloud.
* The development community is very interested in helping debug issues
that arise when upgrading from the latest release to master, since
that arise when upgrading from the latest release to main, since
they provide us an opportunity to fix that category of issue before
our next major release. (Much more so than we are in helping folks
debug other custom changes). That said, we cannot make any
guarantees about how quickly we'll resolve an issue to folks without
a formal support contract.
* We do not support downgrading from `master` to earlier versions, so
* We do not support downgrading from `main` to earlier versions, so
if downtime for your Zulip server is unacceptable, make sure you
have a current
[backup](../production/export-and-import.html#backups) in case the
@ -733,11 +733,11 @@ upgrading to master, make sure you understand:
since the last release. The **Upgrade notes** section will always
be current, even if some new features aren't documented.
* Whenever we push a security or maintenance release, the changes in
that release will always be merged to master; so you can get the
security fixes by upgrading to master.
* You can always upgrade from master to the next major release when it
that release will always be merged to main; so you can get the
security fixes by upgrading to main.
* You can always upgrade from main to the next major release when it
comes out, using either [upgrade-zulip-from-git][] or the release
tarball. So there's no risk of upgrading to `master` resulting in
tarball. So there's no risk of upgrading to `main` resulting in
a system that's not upgradeable back to a normal release.
## Contributing patches

4
docs/subsystems/dependencies.md
View File

@ -208,7 +208,7 @@ See the [README][requirements-readme] file in `requirements/` directory
to learn how to upgrade a single Python package.
[mypy-docs]: ../testing/mypy.md
[requirements-readme]: https://github.com/zulip/zulip/blob/master/requirements/README.md#requirements
[requirements-readme]: https://github.com/zulip/zulip/blob/main/requirements/README.md#requirements
[stack-overflow]: https://askubuntu.com/questions/8653/how-to-keep-processes-running-after-ending-ssh-session
[caching]: https://help.github.com/en/articles/caching-your-github-password-in-git
@ -333,7 +333,7 @@ usually one needs to think about making changes in 3 places:
to be called from `tools/update-prod-static`, which is called by
`tools/build-release-tarball` (for doing Zulip releases) as well as
`tools/upgrade-zulip-from-git` (for deploying a Zulip server off of
master).
main).
[virtualenv]: https://virtualenv.pypa.io/en/stable/
[virtualenv-clone]: https://github.com/edwardgeorge/virtualenv-clone/

2
docs/subsystems/events-system.md
View File

@ -407,7 +407,7 @@ correctly, clients are responsible for discarding events related to
messages that the client has not yet fetched.
Additionally, see
[the master documentation on sending messages](../subsystems/sending-messages.md).
[the main documentation on sending messages](../subsystems/sending-messages.md).
## Schema changes

8
docs/subsystems/release-checklist.md
View File

@ -43,7 +43,7 @@ preparing a new release.
### Executing the release
* Create the release commit, on master (for major releases) or on the
* Create the release commit, on main (for major releases) or on the
release branch (for minor releases):
* Copy the Markdown release notes for the release into
`docs/overview/changelog.md`.
@ -60,7 +60,7 @@ preparing a new release.
GitHub](https://github.com/zulip/zulip/tags); use the text from
`changelog.md` for the release notes.
**Note:** This will trigger the [GitHub action](https://github.com/zulip/zulip/blob/master/tools/oneclickapps/README.md)
**Note:** This will trigger the [GitHub action](https://github.com/zulip/zulip/blob/main/tools/oneclickapps/README.md)
for updating DigitalOcean one-click app image. The action uses the latest release
tarball published on `download.zulip.com` for creating the image.
* Update the [Docker image](https://github.com/zulip/docker-zulip) and
@ -79,7 +79,7 @@ preparing a new release.
* Create a release branch (e.g. `4.x`).
* On the release branch, update `ZULIP_VERSION` in `version.py` to
the present release with a `+git` suffix, e.g. `4.0+git`.
* On master, update `ZULIP_VERSION` to the future major release with
* On main, update `ZULIP_VERSION` to the future major release with
a `-dev+git` suffix, e.g. `5.0-dev+git`. Make a Git tag for this
update commit with a `-dev` suffix, e.g. `5.0-dev`. Push the tag
to both zulip.git and zulip-internal.git to get a correct version
@ -90,4 +90,4 @@ preparing a new release.
* Update `ZULIP_VERSION` to the present release with a `+git`
suffix, e.g. `3.2+git`.
* Update `LATEST_RELEASE_VERSION` with the released version.
* Cherry-pick the changelog changes back to `master`.
* Cherry-pick the changelog changes back to `main`.

10
docs/testing/linters.md
View File

@ -133,14 +133,14 @@ It is the workhorse of our linting system, although in some cases it
dispatches the heavy lifting to other components such as pyflakes,
eslint, and other home grown tools.
You can find the source code [here](https://github.com/zulip/zulip/blob/master/tools/lint).
You can find the source code [here](https://github.com/zulip/zulip/blob/main/tools/lint).
In order for our entire lint suite to run in a timely fashion, the `lint`
script performs several lint checks in parallel by forking out subprocesses.
Note that our project does custom regex-based checks on the code, and we
also customize how we call pyflakes and pycodestyle (pep8). The code for these
types of checks mostly lives [here](https://github.com/zulip/zulip/tree/master/tools/linter_lib).
types of checks mostly lives [here](https://github.com/zulip/zulip/tree/main/tools/linter_lib).
### Special options
@ -216,8 +216,8 @@ Zulip uses two HTML templating systems:
Zulip has an internal tool that validates both types of templates for
correct indentation and matching tags. You can find the code here:
- driver: [check-templates](https://github.com/zulip/zulip/blob/master/tools/check-templates)
- engine: [lib/template_parser.py](https://github.com/zulip/zulip/blob/master/tools/lib/template_parser.py)
- driver: [check-templates](https://github.com/zulip/zulip/blob/main/tools/check-templates)
- engine: [lib/template_parser.py](https://github.com/zulip/zulip/blob/main/tools/lib/template_parser.py)
We exempt some legacy files from indentation checks, but we are hoping to
clean those files up eventually.
@ -226,7 +226,7 @@ clean those files up eventually.
Zulip uses [stylelint](https://github.com/stylelint/stylelint) to lint
its CSS; see our
[configuration](https://github.com/zulip/zulip/blob/master/stylelint.config.js)
[configuration](https://github.com/zulip/zulip/blob/main/stylelint.config.js)
for the rules we currently enforce.
#### Shell scripts

8
docs/testing/testing-with-django.md
View File

@ -69,7 +69,7 @@ Before you write your first tests of Zulip, it is worthwhile to read
the rest of this document.
To get a hang of commonly used testing techniques, read
[zerver/tests/test_example.py](https://github.com/zulip/zulip/blob/master/zerver/tests/test_example.py).
[zerver/tests/test_example.py](https://github.com/zulip/zulip/blob/main/zerver/tests/test_example.py).
You can also read some of the existing tests in `zerver/tests`
to get a feel for other patterns we use.
@ -83,9 +83,9 @@ accidentally regresses the feature in the future, the test will catch
the regression.
Another important files to skim are
[zerver/lib/test_helpers.py](https://github.com/zulip/zulip/blob/master/zerver/lib/test_helpers.py),
[zerver/lib/test_helpers.py](https://github.com/zulip/zulip/blob/main/zerver/lib/test_helpers.py),
which contains test helpers.
[zerver/lib/test_classes.py](https://github.com/zulip/zulip/blob/master/zerver/lib/test_classes.py),
[zerver/lib/test_classes.py](https://github.com/zulip/zulip/blob/main/zerver/lib/test_classes.py),
which contains our `ZulipTestCase` and `WebhookTestCase` classes.
### Setting up data for tests
@ -416,7 +416,7 @@ A detailed description of mocks, along with useful coded snippets, can be found
### Template tests
In [zerver/tests/test_templates.py](https://github.com/zulip/zulip/blob/master/zerver/tests/test_templates.py)
In [zerver/tests/test_templates.py](https://github.com/zulip/zulip/blob/main/zerver/tests/test_templates.py)
we have a test that renders all of our backend templates with
a "dummy" context, to make sure the templates don't have obvious
errors. (These tests won't catch all types of errors; they are

6
docs/testing/testing-with-node.md
View File

@ -44,7 +44,7 @@ there are, you should strive to follow the patterns of the existing tests
and add your own tests.
A good first test to read is
[example1.js](https://github.com/zulip/zulip/blob/master/frontend_tests/node_tests/example1.js).
[example1.js](https://github.com/zulip/zulip/blob/main/frontend_tests/node_tests/example1.js).
(And then there are several other example files.)
## How the node tests work
@ -59,10 +59,10 @@ those slow down the tests a lot, and often don't add much value.
Instead, the preferred model for our unit tests is to mock DOM
manipulations (which in Zulip are almost exclusively done via
`jQuery`) using a custom library
[zjquery](https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zjquery.js).
[zjquery](https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zjquery.js).
The
[unit test file](https://github.com/zulip/zulip/blob/master/frontend_tests/node_tests/zjquery.js)
[unit test file](https://github.com/zulip/zulip/blob/main/frontend_tests/node_tests/zjquery.js)
for `zjquery` is designed to be also serve as nice documentation for
how to use `zjquery`, and is **highly recommended reading** for anyone
working on or debugging the Zulip node tests.

2
docs/testing/testing-with-puppeteer.md
View File

@ -137,7 +137,7 @@ notes above:
verify it does not fail nondeterminstically (see above for notes on
how to get CI to do it for you); this is important to avoid
introducing extremely annoying nondeterministic failures into
master.
main.
- With black-box browser tests like these, it's very important to write your code
to wait for browser's UI to update before taking any action that
assumes the last step was processed by the browser (E.g. after you

2
docs/translating/translating.md
View File

@ -61,7 +61,7 @@ to any languages that you'd like to contribute to (or add new ones).
1. If possible, test your translations (details below).
1. Ask in Zulip for a maintainer to sync the strings from Transifex,
merge them to master, and deploy the update to chat.zulip.org so
merge them to main, and deploy the update to chat.zulip.org so
you can verify them in action there.
Some useful tips for your translating journey:

12
docs/tutorials/life-of-a-request.md
View File

@ -20,7 +20,7 @@ are in your Git checkout under `static`, and are served unminified.
## Static files are [served directly][served-directly] by Nginx
[served-directly]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-frontend/app
[served-directly]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app
Static files include JavaScript, css, static assets (like emoji, avatars),
and user uploads (if stored locally and not on S3).
@ -50,7 +50,7 @@ application.
[Here is the relevant nginx routing configuration.][nginx-config-link]
[nginx-config-link]: https://github.com/zulip/zulip/blob/master/puppet/zulip/files/nginx/zulip-include-frontend/app
[nginx-config-link]: https://github.com/zulip/zulip/blob/main/puppet/zulip/files/nginx/zulip-include-frontend/app
## Django routes the request to a view in urls.py files
@ -70,7 +70,7 @@ on how the REST API handles our user creation example.
## Views serving HTML are internationalized by server path
If we look in
[zproject/urls.py](https://github.com/zulip/zulip/blob/master/zproject/urls.py),
[zproject/urls.py](https://github.com/zulip/zulip/blob/main/zproject/urls.py),
we can see something called `i18n_urls`. These urls show up in the
address bar of the browser, and serve HTML.
@ -135,7 +135,7 @@ This request:
yields a response with this HTTP header:
`Allow: PUT, GET`
We can see this reflected in [zproject/urls.py](https://github.com/zulip/zulip/blob/master/zproject/urls.py):
We can see this reflected in [zproject/urls.py](https://github.com/zulip/zulip/blob/main/zproject/urls.py):
```python
rest_path('users',
@ -151,7 +151,7 @@ The endpoints from the legacy JSON API are written without REST in
mind. They are used extensively by the web client, and use POST.
You can see them in
[zproject/legacy_urls.py](https://github.com/zulip/zulip/blob/master/zproject/legacy_urls.py).
[zproject/legacy_urls.py](https://github.com/zulip/zulip/blob/main/zproject/legacy_urls.py).
### Incoming webhook integrations may not be RESTful
@ -163,7 +163,7 @@ only POST.
For requests that correspond to a REST url pattern, Zulip configures
its url patterns (see
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py))
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py))
so that the action called is `rest_dispatch`. This method will
authenticate the user, either through a session token from a cookie,
or from an `email:api-key` string given via HTTP basic auth for API

14
docs/tutorials/writing-views.md
View File

@ -98,7 +98,7 @@ def home(request: HttpRequest) -> HttpResponse:
### Writing a template
Templates for the main website are found in
[templates/zerver/app](https://github.com/zulip/zulip/tree/master/templates/zerver/app).
[templates/zerver/app](https://github.com/zulip/zulip/tree/main/templates/zerver/app).
## Writing API REST endpoints
@ -109,7 +109,7 @@ view code is in the implementations of API REST endpoints.
The REST API does authentication of the user through `rest_dispatch`,
which is documented in detail at
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py).
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py).
This method will authenticate the user either through a session token
from a cookie on the browser, or from a base64 encoded `email:api-key`
string given via HTTP basic auth for API clients.
@ -174,7 +174,7 @@ the inner decorator.
The implementation of `has_request_variables` is documented in detail
in
[zerver/lib/request.py](https://github.com/zulip/zulip/blob/master/zerver/lib/request.py))
[zerver/lib/request.py](https://github.com/zulip/zulip/blob/main/zerver/lib/request.py))
REQ also helps us with request variable validation. For example:
@ -200,7 +200,7 @@ REQ also helps us with request variable validation. For example:
validator on the value of a string.
See
[zerver/lib/validator.py](https://github.com/zulip/zulip/blob/master/zerver/lib/validator.py)
[zerver/lib/validator.py](https://github.com/zulip/zulip/blob/main/zerver/lib/validator.py)
for more validators and their documentation.
### Deciding which HTTP verb to use
@ -214,7 +214,7 @@ be read with GET, without the expense of the full GET. OPTIONS is also
read-only, and used by clients to determine which HTTP verbs are
available for a given path. This isn't something you need to write, as
it happens automatically in the implementation of `rest_dispatch`--see
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py)
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/main/zerver/lib/rest.py)
for more.
If you're creating new data, try to figure out if the thing you are
@ -259,7 +259,7 @@ database) and lead to a 500 error. If an actions function is
responsible for validation as well, it should have a name starting
with `check_`.
For example, in [zerver/views/realm.py](https://github.com/zulip/zulip/blob/master/zerver/views/realm.py):
For example, in [zerver/views/realm.py](https://github.com/zulip/zulip/blob/main/zerver/views/realm.py):
```py
@require_realm_admin
@ -284,7 +284,7 @@ Zulip realm).
You should always use `channel.<method>` to make an `HTTP <method>` call
to the Zulip JSON API. As an example, in
[static/js/admin.js](https://github.com/zulip/zulip/blob/master/static/js/admin.js)
[static/js/admin.js](https://github.com/zulip/zulip/blob/main/static/js/admin.js)
```js
var url = "/json/realm";

2
frontend_tests/node_tests/zblueslip.js
View File

@ -23,7 +23,7 @@ What is zblueslip?
The code we are testing lives here:
https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zblueslip.js
https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zblueslip.js
Read the following contents for an overview of how zblueslip works. Also take a
look at `node_tests/people_errors.js` for actual usage of this module.

2
frontend_tests/node_tests/zjquery.js
View File

@ -25,7 +25,7 @@ What is zjquery?
The code we are testing lives here:
https://github.com/zulip/zulip/blob/master/frontend_tests/zjsunit/zjquery.js
https://github.com/zulip/zulip/blob/main/frontend_tests/zjsunit/zjquery.js
*/

2
templates/zerver/api/incoming-webhooks-overview.md
View File

@ -66,7 +66,7 @@ process.
* Document the integration (required for getting it merged into Zulip). You
can template off an existing guide, like
[this one](https://raw.githubusercontent.com/zulip/zulip/master/zerver/webhooks/github/doc.md).
[this one](https://raw.githubusercontent.com/zulip/zulip/main/zerver/webhooks/github/doc.md).
This should not take more than 15 minutes, even if you don't speak English
as a first language (we'll clean up the text before merging).

2
templates/zerver/api/incoming-webhooks-walkthrough.md
View File

@ -456,7 +456,7 @@ See
[our guide on documenting an integration][integration-docs-guide]
for further details, including how to easily create the message
screenshot. Mostly you should plan on templating off an existing guide, like
[this one](https://raw.githubusercontent.com/zulip/zulip/master/zerver/webhooks/github/doc.md).
[this one](https://raw.githubusercontent.com/zulip/zulip/main/zerver/webhooks/github/doc.md).
[integration-docs-guide]: https://zulip.readthedocs.io/en/latest/documentation/integrations.html

2
templates/zerver/api/integrations-overview.md
View File

@ -65,5 +65,5 @@ us](/help/contact-support) and we'll see what we can do.
built on top of this API, so it can do anything a human user can do. Most
but not all of the endpoints are documented on this site; if you need
something that isn't there check out Zulip's
[REST endpoints](https://github.com/zulip/zulip/blob/master/zproject/urls.py)
[REST endpoints](https://github.com/zulip/zulip/blob/main/zproject/urls.py)
or [contact us](/help/contact-support) and we'll help you out.

2
templates/zerver/help/import-from-mattermost.md
View File

@ -139,7 +139,7 @@ skipping "Step 3: Create a Zulip organization, and log in" (you'll
create your Zulip organization via the data import tool instead).
Use [upgrade-zulip-from-git][upgrade-zulip-from-git] to
upgrade your Zulip server to the latest `master` branch.
upgrade your Zulip server to the latest `main` branch.
Log in to a shell on your Zulip server as the `zulip` user. To import with
the most common configuration, run the following commands, replacing

4
templates/zerver/help/include/git-append-branches.md
View File

@ -1,4 +1,4 @@
You can also limit the notifications you receive to specific branches
by appending `?branches=master,development` to the end of the URL,
where `master` and `development` are the branches you'd like to be
by appending `?branches=main,development` to the end of the URL,
where `main` and `development` are the branches you'd like to be
notified about.

2
templates/zerver/help/include/git-webhook-url-with-branches-indented.md
View File

@ -1,4 +1,4 @@
You can also limit the branches you receive notifications for by
specifying them in a comma-separated list at the end of the URL,
like so:
`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=master,development`
`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=main,development`

2
templates/zerver/help/include/git-webhook-url-with-branches.md
View File

@ -2,4 +2,4 @@ You can also limit the branches you receive notifications for by
specifying them in a comma-separated list at the end of the URL,
like so:
`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=master,development`
`{{ api_url }}{{ integration_url }}?api_key=abcdefgh&stream={{ recommended_stream_name }}&branches=main,development`

2
tools/cache-zulip-git-version
View File

@ -5,7 +5,7 @@ cd "$(dirname "$0")/.."
remote="$(git config zulip.zulipRemote)" || remote=upstream
{
git describe --always --tags --match='[0-9]*'
branches="$(git for-each-ref --format='%(objectname)' "refs/remotes/$remote/master" "refs/remotes/$remote/*.x")"
branches="$(git for-each-ref --format='%(objectname)' "refs/remotes/$remote/main" "refs/remotes/$remote/*.x")"
mapfile -t branches <<<"$branches"
if merge_base="$(git merge-base -- HEAD "${branches[@]}")"; then
git describe --always --tags --match='[0-9]*' -- "$merge_base"

12
tools/clean-branches
View File

@ -2,9 +2,9 @@
set -e
# usage: clean-branches
# Deletes any local branches which are ancestors of origin/master,
# Deletes any local branches which are ancestors of origin/main,
# and also any branches in origin which are ancestors of
# origin/master and are named like $USER-*.
# origin/main and are named like $USER-*.
# usage: clean-branches --reviews
# Deletes all the above mentioned branches as well as branches
@ -18,13 +18,13 @@ fi
push_args=()
function is_merged() {
! git rev-list -n 1 origin/master.."$1" | grep -q .
! git rev-list -n 1 origin/main.."$1" | grep -q .
}
function clean_ref() {
ref="$1"
case "$ref" in
*/master | */HEAD)
*/main | */HEAD)
return
;;
@ -56,8 +56,8 @@ function clean_ref() {
esac
}
if [ "$(git symbolic-ref HEAD)" != 'refs/heads/master' ]; then
echo "Check out master before you run this script." >&2
if [ "$(git symbolic-ref HEAD)" != 'refs/heads/main' ]; then
echo "Check out main before you run this script." >&2
exit 1
fi

6
tools/commit-message-lint
View File

@ -1,6 +1,6 @@
#!/usr/bin/env bash
# Lint all commit messages that are newer than upstream/master if running
# Lint all commit messages that are newer than upstream/main if running
# locally or the commits in the push or PR if in CircleCI.
# The rules can be found in /.gitlint
@ -12,9 +12,9 @@ $(git remote -v)
" =~ '
'([^[:space:]]*)[[:space:]]*(https://github\.com/|ssh://git@github\.com/|git@github\.com:)"$repository"(\.git|/)?\ \(fetch\)'
' ]]; then
range="${BASH_REMATCH[1]}/master..HEAD"
range="${BASH_REMATCH[1]}/main..HEAD"
else
range="upstream/master..HEAD"
range="upstream/main..HEAD"
fi
commits=$(git log "$range" | wc -l)

8
tools/deploy-branch
View File

@ -15,7 +15,7 @@ branch=$1
branch_ref=$(git rev-list --max-count=1 "$branch") || error_out "Unknown branch: $branch"
if [ "$old_ref" == "$branch_ref" ]; then
new_ref=master
new_ref=main
else
if ref_name=$(git describe --all --exact "$old_ref"); then
new_ref=$(echo "$ref_name" | perl -pe 's{^(heads|remotes)/}{}')
@ -28,10 +28,10 @@ fi
git fetch -p
git rebase origin/master "$branch" || error_out "Rebase onto origin/master failed"
git rebase origin/main "$branch" || error_out "Rebase onto origin/main failed"
git push . HEAD:master
git push origin master || error_out "Push of master to origin/master failed"
git push . HEAD:main
git push origin main || error_out "Push of main to origin/main failed"
git checkout "$new_ref"
git branch -D "$branch"

6
tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py
View File

@ -32,7 +32,7 @@ EXCLUDED_URLS = [
"https://www.transifex.com/zulip/zulip/announcements/",
"https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh",
# Requires authentication
"https://circleci.com/gh/zulip/zulip/tree/master",
"https://circleci.com/gh/zulip/zulip/tree/main",
"https://circleci.com/gh/zulip/zulip/16617",
"https://www.linkedin.com/company/zulip-project",
# Returns 403 errors to HEAD requests
@ -54,8 +54,8 @@ VNU_IGNORE_REGEX = re.compile(r"|".join(VNU_IGNORE))
DEPLOY_ROOT = os.path.abspath(os.path.join(__file__, "../../../../../.."))
ZULIP_SERVER_GITHUB_FILE_URL_PREFIX = "https://github.com/zulip/zulip/blob/master"
ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/master"
ZULIP_SERVER_GITHUB_FILE_URL_PREFIX = "https://github.com/zulip/zulip/blob/main"
ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/main"
class BaseDocumentationSpider(scrapy.Spider):

2
tools/droplets/README.md
View File

@ -127,7 +127,7 @@ Rough steps:
probably have to be logged in in the Zulip organization view, rather than
via your personal account.
1. `ssh zulipdev@base.zulipdev.org`
1. `git pull upstream master`
1. `git pull upstream main`
1. `tools/provision`
1. `git clean -f`, in case things were added/removed from `.gitignore`.
1. `tools/run-dev.py`, let it run to completion, and then Ctrl-C (to clear

2
tools/fetch-rebase-pull-request
View File

@ -12,6 +12,6 @@ remote=${2:-"upstream"}
set -x
git fetch "$remote" "pull/$request_id/head"
git checkout -B "review-${request_id}" "$remote/master"
git checkout -B "review-${request_id}" "$remote/main"
git reset --hard FETCH_HEAD
git pull --rebase

2
tools/lib/test_script.py
View File

@ -39,7 +39,7 @@ NEED_TO_DOWNGRADE = """
It looks like you checked out a branch that expects an older
version of dependencies than the version you provisioned last.
This may be ok, but it's likely that you either want to rebase
your branch on top of upstream/master or re-provision your VM.
your branch on top of upstream/main or re-provision your VM.
Do this: `./tools/provision`
"""

4
tools/push-to-pull-request
View File

@ -7,9 +7,9 @@ usage: $0 [--merge] PULL_REQUEST_ID [REMOTE]
Force-push our HEAD to the given GitHub pull request branch.
Useful for a maintainer to run just before pushing to master,
Useful for a maintainer to run just before pushing to main,
after tweaking the branch and/or rebasing to latest. This causes
GitHub to see the subsequent push to master as representing a
GitHub to see the subsequent push to main as representing a
merge of the PR, rather than requiring the PR to be manually
(and to the casual observer misleadingly) closed instead.

16
tools/review
View File

@ -33,21 +33,21 @@ def check_git_pristine() -> None:
exit("Git is not pristine:\n" + output)
def ensure_on_clean_master() -> None:
def ensure_on_clean_main() -> None:
branch = get_git_branch()
if branch != "master":
if branch != "main":
exit(f"You are still on a feature branch: {branch}")
check_git_pristine()
run(["git", "fetch", "upstream", "master"])
run(["git", "rebase", "upstream/master"])
run(["git", "fetch", "upstream", "main"])
run(["git", "rebase", "upstream/main"])
def create_pull_branch(pull_id: int) -> None:
run(["git", "fetch", "upstream", f"pull/{pull_id}/head"])
run(["git", "checkout", "-B", f"review-{pull_id}", "FETCH_HEAD"])
run(["git", "rebase", "upstream/master"])
run(["git", "log", "upstream/master..", "--oneline"])
run(["git", "diff", "upstream/master..", "--name-status"])
run(["git", "rebase", "upstream/main"])
run(["git", "log", "upstream/main..", "--oneline"])
run(["git", "diff", "upstream/main..", "--name-status"])
print()
print(f"PR: {pull_id}")
@ -60,7 +60,7 @@ def review_pr() -> None:
except Exception:
exit("please provide an integer pull request id")
ensure_on_clean_master()
ensure_on_clean_main()
create_pull_branch(pull_id)

2
tools/setup/install-aws-server
View File

@ -18,7 +18,7 @@ if [ -z "$SERVER" ] || [ -z "$ROLES" ]; then
echo
echo "[repo]"
echo "repo_url=git@github.com:zulip/zulip.git"
echo "branch=master"
echo "branch=main"
echo "[aws]"
echo "zone_id=Z2U988IEXAMPLE"
echo "security_groups=sg-01234567"

4
zerver/lib/markdown/__init__.py
View File

@ -714,8 +714,8 @@ class InlineInterestingLinkProcessor(markdown.treeprocessors.Treeprocessor):
# See https://github.com/zulip/zulip/issues/4658 for more information
parsed_url = urllib.parse.urlparse(url)
if parsed_url.netloc == "github.com" or parsed_url.netloc.endswith(".github.com"):
# https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png ->
# https://raw.githubusercontent.com/zulip/zulip/master/static/images/logo/zulip-icon-128x128.png
# https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png ->
# https://raw.githubusercontent.com/zulip/zulip/main/static/images/logo/zulip-icon-128x128.png
split_path = parsed_url.path.split("/")
if len(split_path) > 3 and split_path[3] == "blob":
return urllib.parse.urljoin(

2
zerver/lib/test_data.source.txt
View File

@ -165,7 +165,7 @@ This project seems to be proceeding well; I'm looking forward to testing it
out soon.
I should clarify what I said earlier about "not having anything since 1.6
related to this." On master we are actually touching a lot of email-related
related to this." On main we are actually touching a lot of email-related
code.
ah, I see, the other files just isolated them, makes sense. I guess I'll

2
zerver/migrations/0209_user_profile_no_empty_password.py
View File

@ -60,7 +60,7 @@ def ensure_no_empty_passwords(apps: StateApps, schema_editor: DatabaseSchemaEdit
# Because we're backporting this migration to the Zulip 2.0.x
# series, we've given it migration number 0209, which is a
# duplicate with an existing migration already merged into Zulip
# master. Migration 0247_realmauditlog_event_type_to_int.py
# main. Migration 0247_realmauditlog_event_type_to_int.py
# changes the format of RealmAuditLog.event_type, so we need the
# following conditional block to determine what values to use when
# searching for the relevant events in that log.

2
zerver/tests/test_example.py
View File

@ -364,7 +364,7 @@ class TestQueryCounts(ZulipTestCase):
# fails, we'll want to understand the new queries and whether
# they're necessary. You can investiate whether the changes
# are expected/sensible by comparing print(queries) between
# your branch and master.
# your branch and main.
hamlet = self.example_user("hamlet")
cordelia = self.example_user("cordelia")

4
zerver/tests/test_markdown.py
View File

@ -837,12 +837,12 @@ class MarkdownTest(ZulipTestCase):
def test_inline_github_preview(self) -> None:
# Test photo album previews
msg = "Test: https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png"
msg = "Test: https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png"
converted = markdown_convert_wrapper(msg)
self.assertEqual(
converted,
'<p>Test: <a href="https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png">https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png</a></p>\n<div class="message_inline_image"><a href="https://github.com/zulip/zulip/blob/master/static/images/logo/zulip-icon-128x128.png"><img data-src-fullsize="/thumbnail?url=https%3A%2F%2Fraw.githubusercontent.com%2Fzulip%2Fzulip%2Fmaster%2Fstatic%2Fimages%2Flogo%2Fzulip-icon-128x128.png&amp;size=full" src="/thumbnail?url=https%3A%2F%2Fraw.githubusercontent.com%2Fzulip%2Fzulip%2Fmaster%2Fstatic%2Fimages%2Flogo%2Fzulip-icon-128x128.png&amp;size=thumbnail"></a></div>',
'<p>Test: <a href="https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png">https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png</a></p>\n<div class="message_inline_image"><a href="https://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png"><img data-src-fullsize="/thumbnail?url=https%3A%2F%2Fraw.githubusercontent.com%2Fzulip%2Fzulip%2Fmain%2Fstatic%2Fimages%2Flogo%2Fzulip-icon-128x128.png&amp;size=full" src="/thumbnail?url=https%3A%2F%2Fraw.githubusercontent.com%2Fzulip%2Fzulip%2Fmain%2Fstatic%2Fimages%2Flogo%2Fzulip-icon-128x128.png&amp;size=thumbnail"></a></div>',
)
msg = "Test: https://developer.github.com/assets/images/hero-circuit-bg.png"

4
zerver/tornado/event_queue.py
View File

@ -1104,7 +1104,7 @@ def process_message_update_event(
# TODO/compatibility: Translation code for the rename of
# `push_notify_user_ids` to `online_push_user_ids`. Remove this
# when one can no longer directly upgrade from 4.x to master.
# when one can no longer directly upgrade from 4.x to main.
online_push_user_ids = set()
if "online_push_user_ids" in event_template:
online_push_user_ids = set(event_template.pop("online_push_user_ids"))
@ -1290,7 +1290,7 @@ def process_notification(notice: Mapping[str, Any]) -> None:
# queue at the time of upgrade.
#
# TODO/compatibility: Remove this block once you can no
# longer directly upgrade directly from 4.x to master.
# longer directly upgrade directly from 4.x to main.
user_ids: List[int] = [user["id"] for user in cast(List[Mapping[str, Any]], users)]
else:
user_ids = cast(List[int], users)

2
zerver/worker/queue_processors.py
View File

@ -508,7 +508,7 @@ class UserActivityWorker(LoopQueueProcessingWorker):
# event["client_id"] directly.
#
# TODO/compatibility: We can delete this once it is no
# longer possible to directly upgrade from 2.1 to master.
# longer possible to directly upgrade from 2.1 to main.
if event["client"] not in self.client_id_map:
client = get_client(event["client"])
self.client_id_map[event["client"]] = client.id