Rename default branch to ‘main’.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

README.md

@@ -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)
+[![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/master.svg)](https://codecov.io/gh/zulip/zulip/branch/master)
+[![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

docs/contributing/code-reviewing.md

@@ -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

docs/development/setup-vagrant.md

@@ -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

docs/development/test-install.md

@@ -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

docs/development/using.md

@@ -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

docs/documentation/integrations.md

@@ -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
 

docs/documentation/user.md

@@ -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

docs/git/cheat-sheet.md

@@ -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 -i main`
-    - `git rebase upstream/master`
+    - `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 -i main`: interactive rebasing current branch with main branch
-    - `git rebase upstream/master`: rebasing current branch with master branch from upstream repository
+    - `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
 

docs/git/pull-requests.md

@@ -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

docs/git/reviewing.md

@@ -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

docs/git/troubleshooting.md

@@ -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

docs/git/using.md

@@ -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().
+  main                      f0eaee6 [origin/main] bug: Fix traceback in get_missed_message_token_from_address().
-  remotes/origin/HEAD       -> origin/master
+  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/origin/main       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/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
+Next, check out your `main` branch and [rebase][gitbook-git-rebase] it on top
-of `upstream/master`:
+of `upstream/main`:
 
 ```console
-$ git checkout master
+$ git checkout main
-Switched to branch 'master'
+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
+This will rollback any changes you've made to main, update it from
-`upstream/master`, and then re-apply your changes. Rebasing keeps the commit
+`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 checkout main
-$ git push origin master
+$ 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
+$ git checkout main
-Switched to branch 'master'
+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.

docs/git/working-copies.md

@@ -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
 

docs/git/zulip-tools.md

@@ -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
+$ git checkout main
-Switched to branch 'master'
+Switched to branch 'main'
-Your branch is up-to-date with 'origin/master'.
+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
++ git checkout upstream/main -b review-1913
-Branch review-1913 set up to track remote branch master from upstream.
+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.
+1. Local branches that are ancestors of origin/main.
-2. Branches in origin that are ancestors of origin/master and named like `$USER-*`.
+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

docs/overview/changelog.md

@@ -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

docs/overview/release-lifecycle.md

@@ -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
+* [Zulip Cloud](https://zulip.com) essentially runs the main
-  branch. It is usually a few days behind master (with some
+  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
+  Zulip development community, is upgraded to main several times
-  every week.  We also often "test deploy" changes not yet in master
+  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

docs/production/authentication-methods.md

@@ -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

docs/production/deployment.md

@@ -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
+[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/master/puppet/zulip/manifests/profile/standalone.pp
+[standalone.pp]: https://github.com/zulip/zulip/blob/main/puppet/zulip/manifests/profile/standalone.pp
-[zulipchat-puppet]: https://github.com/zulip/zulip/tree/master/puppet/zulip_ops/manifests
+[zulipchat-puppet]: https://github.com/zulip/zulip/tree/main/puppet/zulip_ops/manifests
 
 ### Apache2 configuration
 

docs/production/export-and-import.md

@@ -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

docs/production/install-existing-server.md

@@ -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
 ```
 

docs/production/requirements.md

@@ -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
 

docs/production/settings.md

@@ -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

docs/production/upgrade-or-modify.md

@@ -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
+Zulip core team and merged into main, skip to [this
-section](#applying-changes-from-master).
+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
+upgrade to Zulip main using [upgrade-zulip-from-git][].  Before
-upgrading to master, make sure you understand:
+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
+* The `main` branch is under very active development; dozens of new
-  changes are integrated into it on most days.  The `master` branch
+  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
+  that release will always be merged to main; so you can get the
-  security fixes by upgrading to master.
+  security fixes by upgrading to main.
-* You can always upgrade from master to the next major release when it
+* 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

docs/subsystems/dependencies.md

@@ -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/

docs/subsystems/events-system.md

@@ -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
 

docs/subsystems/release-checklist.md

@@ -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`.

docs/testing/linters.md

@@ -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)
+- driver: [check-templates](https://github.com/zulip/zulip/blob/main/tools/check-templates)
-- engine: [lib/template_parser.py](https://github.com/zulip/zulip/blob/master/tools/lib/template_parser.py)
+- 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

docs/testing/testing-with-django.md

@@ -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

docs/testing/testing-with-node.md

@@ -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.

docs/testing/testing-with-puppeteer.md

@@ -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

docs/translating/translating.md

@@ -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:

docs/tutorials/life-of-a-request.md

@@ -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

docs/tutorials/writing-views.md

@@ -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";

frontend_tests/node_tests/zblueslip.js

@@ -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.

frontend_tests/node_tests/zjquery.js

@@ -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
 
 */
 

templates/zerver/api/incoming-webhooks-overview.md

@@ -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).
 

templates/zerver/api/incoming-webhooks-walkthrough.md

@@ -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
 

templates/zerver/api/integrations-overview.md

@@ -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.

templates/zerver/help/import-from-mattermost.md

@@ -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

templates/zerver/help/include/git-append-branches.md

@@ -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,
+by appending `?branches=main,development` to the end of the URL,
-where `master` and `development` are the branches you'd like to be
+where `main` and `development` are the branches you'd like to be
 notified about.

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

@@ -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`

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

@@ -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`

tools/cache-zulip-git-version

@@ -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"

tools/clean-branches

@@ -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
+if [ "$(git symbolic-ref HEAD)" != 'refs/heads/main' ]; then
-    echo "Check out master before you run this script." >&2
+    echo "Check out main before you run this script." >&2
     exit 1
 fi
 

tools/commit-message-lint

@@ -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)

tools/deploy-branch

@@ -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 . HEAD:main
-git push origin master || error_out "Push of master to origin/master failed"
+git push origin main || error_out "Push of main to origin/main failed"
 
 git checkout "$new_ref"
 git branch -D "$branch"

tools/documentation_crawler/documentation_crawler/spiders/common/spiders.py

@@ -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_FILE_URL_PREFIX = "https://github.com/zulip/zulip/blob/main"
-ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/master"
+ZULIP_SERVER_GITHUB_DIRECTORY_URL_PREFIX = "https://github.com/zulip/zulip/tree/main"
 
 
 class BaseDocumentationSpider(scrapy.Spider):

tools/droplets/README.md

@@ -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

tools/fetch-rebase-pull-request

@@ -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

tools/lib/test_script.py

@@ -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`
 """

tools/push-to-pull-request

@@ -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.
 

tools/review

@@ -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", "fetch", "upstream", "main"])
-    run(["git", "rebase", "upstream/master"])
+    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", "rebase", "upstream/main"])
-    run(["git", "log", "upstream/master..", "--oneline"])
+    run(["git", "log", "upstream/main..", "--oneline"])
-    run(["git", "diff", "upstream/master..", "--name-status"])
+    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)
 
 

tools/setup/install-aws-server

@@ -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"

zerver/lib/markdown/__init__.py

@@ -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://github.com/zulip/zulip/blob/main/static/images/logo/zulip-icon-128x128.png ->
-            # https://raw.githubusercontent.com/zulip/zulip/master/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(

zerver/lib/test_data.source.txt

@@ -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

zerver/migrations/0209_user_profile_no_empty_password.py

@@ -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.

zerver/tests/test_example.py

@@ -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")
 

zerver/tests/test_markdown.py

@@ -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"

zerver/tornado/event_queue.py

@@ -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)

zerver/worker/queue_processors.py

@@ -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