doc: update internal references to master branch

.github/PULL_REQUEST_TEMPLATE.md

@@ -6,7 +6,7 @@ http://yt-project.org/docs/dev/developing/index.html-->
 example "Raises ValueError on Non-Numeric Input to set_xlim".  Please avoid
 non-descriptive titles such as "Addresses issue #8576".-->
 
-<!--If you are able to do so, please do not create the PR out of master, but out
+<!--If you are able to do so, please do not create the PR out of main, but out
 of a separate branch. -->
 
 ## PR Summary

.github/workflows/rules-checks.yaml

@@ -5,7 +5,7 @@ jobs:
   h5py-bad-practices:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@master
+    - uses: actions/checkout@main
     - name: check-h5py-import
       # check that we don't alias h5py to h5
       # reason: discoverability is important since this module's api

CONTRIBUTING.rst

@@ -308,7 +308,7 @@ directory.
 
    $ cd yt-git
 
-Verify that you are on the master branch of yt by running:
+Verify that you are on the ``main`` branch of yt by running:
 
 .. code-block:: bash
 
@@ -334,14 +334,14 @@ You can always return to the most recent version of the code by executing the
 same command as above with the most recent revision specifier in the
 repository. However, using ``git log`` when you're checked out to an older
 revision specifier will not show more recent changes to the repository. An
-alternative option is to use ``checkout`` on a branch. In yt the ``master``
-branch is our primary development branch, so checking out ``master`` should
-return you to the tip (or most up-to-date revision specifier) on the ``master``
+alternative option is to use ``checkout`` on a branch. In yt the ``main``
+branch is our primary development branch, so checking out ``main`` should
+return you to the tip (or most up-to-date revision specifier) on the ``main``
 branch.
 
 .. code-block:: bash
 
-   $ git checkout master
+   $ git checkout main
 
 Lastly, if you want to use this new downloaded version of your yt repository as
 the *active* version of yt on your computer (i.e. the one which is executed when
@@ -546,12 +546,12 @@ chat or on the mailing list to walk you through any troubles you might have.
 Here are some general suggestions for using git with yt:
 
 * Although not necessary, a common development work flow is to create a local
-  named branch other than ``master`` to address a feature request or bugfix. If
+  named branch other than ``main`` to address a feature request or bugfix. If
   the dev work addresses a specific yt GitHub issue, you may include that issue
   number in the branch name. For example, if you want to work on issue number X
   regarding a cool new slice plot feature, you might name the branch:
   ``cool_new_plot_feature_X``. When you're ready to share your work, push your
-  feature branch to your remote and create a pull request to the ``master``
+  feature branch to your remote and create a pull request to the ``main``
   branch of the yt-project's repository.
 * When contributing changes, you might be asked to make a handful of
   modifications to your source code.  We'll work through how to do this with
@@ -655,7 +655,7 @@ Here's a more detailed flowchart of how to submit changes.
      protocol.
 
      .. _SSH key: https://help.github.com/en/articles/connecting-to-github-with-ssh/
-#. Issue a pull request at https://github.com/yt-project/yt/pull/new/master A
+#. Issue a pull request at https://github.com/yt-project/yt/pull/new/main A
    pull request is essentially just asking people to review and accept the
    modifications you have made to your personal version of the code.
 
@@ -676,13 +676,13 @@ straightforward.
 Once your pull request is merged, sync up with the main yt repository by pulling
 from the ``upstream`` remote::
 
-     git checkout master
-     git pull upstream master
+     git checkout main
+     git pull upstream main
 
 You might also want to sync your fork of yt on GitHub::
 
      # sync my fork of yt with upstream
-     git push origin master
+     git push origin main
 
 And delete the branch for the merged pull request::
 

README.md

@@ -2,15 +2,15 @@
 
 [![Users' Mailing List](https://img.shields.io/badge/Users-List-lightgrey.svg)](https://mail.python.org/archives/list/[email protected]//)
 [![Devel Mailing List](https://img.shields.io/badge/Devel-List-lightgrey.svg)](https://mail.python.org/archives/list/[email protected]//)
-[![Build Status](https://img.shields.io/travis/yt-project/yt.svg?branch=master)](https://travis-ci.org/yt-project/yt)
+[![Build Status](https://img.shields.io/travis/yt-project/yt.svg?branch=main)](https://travis-ci.org/yt-project/yt)
 [![Latest Documentation](https://img.shields.io/badge/docs-latest-brightgreen.svg)](http://yt-project.org/docs/dev/)
 [![Data Hub](https://img.shields.io/badge/data-hub-orange.svg)](https://hub.yt/)
 [![Powered by NumFOCUS](https://img.shields.io/badge/powered%20by-NumFOCUS-orange.svg?style=flat&colorA=E1523D&colorB=007D8A)](http://numfocus.org)
 [![Sponsor our Project](https://img.shields.io/badge/donate-to%20yt-blueviolet)](https://numfocus.salsalabs.org/donate-to-yt/index.html)
 [![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
 
 <!---
-[![codecov](https://codecov.io/gh/yt-project/yt/branch/master/graph/badge.svg)](https://codecov.io/gh/yt-project/yt)
+[![codecov](https://codecov.io/gh/yt-project/yt/branch/main/graph/badge.svg)](https://codecov.io/gh/yt-project/yt)
 --->
 <a href="http://yt-project.org"><img src="doc/source/_static/yt_logo.png" width="300"></a>
 

doc/install_script.sh

@@ -38,7 +38,7 @@ INST_NETCDF4=1  # Install netcdf4 and its python bindings?
 INST_POOCH=1    # Install pooch?
 
 # This is the branch we will install from for INST_YT_SOURCE=1
-BRANCH="master"
+BRANCH="main"
 
 # These variables control which miniconda version is used
 

doc/source/about/index.rst

@@ -31,7 +31,7 @@ contributions to the code, see
 `our members website. <https://yt-project.org/members.html>`_
 
 For an up-to-date list of everyone who has contributed to the yt codebase,
-see the current `CREDITS <https://github.com/yt-project/yt/blob/master/CREDITS>`_ file.
+see the current `CREDITS <https://github.com/yt-project/yt/blob/main/CREDITS>`_ file.
 For a more detailed breakup of contributions made by individual users, see out
 `Open HUB page <https://www.openhub.net/p/yt_amr/contributors?query=&sort=commits>`_.
 

doc/source/developing/releasing.rst

@@ -12,7 +12,7 @@ from the version number used. Version numbers should follow the scheme
   once a month. These releases should contain only fixes for bugs discovered in
   earlier releases and should not contain new features or API changes. Bugfix
   releases should increment the ``PATCH`` version number. Bugfix releases should
-  *not* be generated by merging from the ``master`` branch, instead bugfix pull
+  *not* be generated by merging from the ``main`` branch, instead bugfix pull
   requests should be manually backported. Version ``3.2.2`` is a bugfix release.
 
 * Minor releases
@@ -24,7 +24,7 @@ from the version number used. Version numbers should follow the scheme
   backwards-incompatible changes and should not change APIs.  If an API change
   is deemed to be necessary, the old API should continue to function but might
   trigger deprecation warnings. Minor releases should happen by merging the
-  ``master`` branch into the ``stable`` branch. Minor releases should increment the
+  ``main`` branch into the ``stable`` branch. Minor releases should increment the
   ``MINOR`` version number and reset the ``PATCH`` version number to zero.
   Version ``3.3.0`` is a minor release.
 
@@ -35,7 +35,7 @@ from the version number used. Version numbers should follow the scheme
   include arbitrary changes to the library. Major version releases should only
   happen after extensive discussion and vetting among the developer and user
   community. Like minor releases, a major release should happen by merging the
-  ``master`` branch into the ``stable`` branch. Major releases should increment the
+  ``main`` branch into the ``stable`` branch. Major releases should increment the
   ``MAJOR`` version number and reset the ``MINOR`` and ``PATCH`` version numbers
   to zero. If it ever happens, version ``4.0.0`` will be a major release.
 
@@ -48,9 +48,9 @@ Doing a Bugfix Release
 As described above, bugfix releases are regularly scheduled updates for minor
 releases to ensure fixes for bugs make their way out to users in a timely
 manner. Since bugfix releases should not include new features, we do not issue
-bugfix releases by simply merging from the development ``master`` branch into
+bugfix releases by simply merging from the development ``main`` branch into
 the ``stable`` branch.  Instead, we manually cherry-pick bugfixes from the from
-``master`` branch onto the ``stable`` branch.
+``main`` branch onto the ``stable`` branch.
 
 You may find the ``pr_backport.py`` script located in the ``scripts`` folder at
 the root of the repository to be helpful. This script uses the github API to
@@ -69,9 +69,9 @@ Doing a Minor or Major Release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This is much simpler than a bugfix release.  All that needs to happen is the
-``master`` branch must get merged into the ``stable`` branch, and any conflicts
+``main`` branch must get merged into the ``stable`` branch, and any conflicts
 that happen must be resolved, almost always in favor of the state of the code on
-the ``master`` branch.
+the ``main`` branch.
 
 
 Incrementing Version Numbers and Tagging a Release
@@ -175,11 +175,11 @@ build the latest tag of yt. You may also need to update elsewhere in the file if
 yt's dependencies changed or if yt dropped or added support for a Python
 version. To generate new wheels you need to push the changes to GitHub. A good
 process to follow is to first submit a pull request to test the changes and make sure
-the wheels can be built. Once they pass, you can merge the changes into master
+the wheels can be built. Once they pass, you can merge the changes into ``main``
 and wait for the wheel files to be uploaded to
 https://anaconda.org/multibuild-wheels-staging/yt/files
 (note that the wheels will not be uploaded until the changes have been
-merged into master). Once the wheels are uploaded, download the
+merged into ``main``). Once the wheels are uploaded, download the
 wheel files for the release and copy them to the ``dist`` folder in the yt
 repository so that they are sitting next to the source distribution
 we created earlier. Here's a

doc/source/installing.rst

@@ -63,23 +63,23 @@ will work best for you depends on your precise situation:
 
 .. _branches-of-yt:
 
-Branches of yt: ``master``, ``stable``, and ``yt-2.x``
+Branches of yt: ``main``, ``stable``, and ``yt-2.x``
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 Before you install yt, you must decide which branch (i.e. version) of the code
 you prefer to use:
 
-* ``master`` -- The most up-to-date *development* version with the most current
+* ``main`` -- The most up-to-date *development* version with the most current
   features but sometimes unstable (the development version of the next release).
 * ``stable`` -- The latest stable release of ``yt-3.x``.
 * ``yt-2.x`` -- The last stable release of ``yt-2.x``.
 
 If this is your first time using the code, we recommend using ``stable``, unless
 you specifically need some piece of brand-new functionality only available in
-``master`` or need to run an old script developed for ``yt-2.x``.  There were major
+``main`` or need to run an old script developed for ``yt-2.x``.  There were major
 API and functionality changes made in yt for version 3.0.  For a detailed
 description of the changes between versions 2.x (e.g. branch ``yt-2.x``) and 3.x
-(e.g. branches ``master`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
+(e.g. branches ``main`` and ``stable``) see :ref:`yt3differences`.  Lastly, don't
 feel like you're locked into one branch when you install yt, because you can
 easily change the active branch by following the instructions in
 :ref:`switching-between-yt-versions`.
@@ -113,13 +113,13 @@ You can download the installation script with the following command:
 
 .. code-block:: bash
 
-  $ wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
+  $ wget https://raw.githubusercontent.com/yt-project/yt/main/doc/install_script.sh
 
 If you do not have ``wget``, the following should also work:
 
 .. code-block:: bash
 
-  $ curl -OL https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
+  $ curl -OL https://raw.githubusercontent.com/yt-project/yt/main/doc/install_script.sh
 
 By default, the bash install script will create a python environment based on
 the `miniconda python distribution <https://docs.conda.io/en/latest/miniconda.html>`_,
@@ -334,7 +334,7 @@ you to see the tip of the development branch.
 
 .. code-block:: bash
 
-  $ git checkout master
+  $ git checkout main
   $ pip install -e .
 
 This will make sure you are running a version of yt corresponding to the
@@ -400,7 +400,7 @@ development version of yt instead of the latest stable release, you will need
 
   $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ git checkout master
+  $ git checkout main
   $ pip install . --user --install-option="--prefix="
 
 .. note::
@@ -432,7 +432,7 @@ repository the "active" installed copy:
 
   $ git clone https://github.com/yt-project/yt
   $ cd yt
-  $ git checkout master
+  $ git checkout main
   $ pip install -e . --user --install-option="--prefix="
 
 As above, you can leave off ``--user --install-option="--prefix="`` if you want to install yt into
@@ -502,7 +502,7 @@ for more details.
 
 .. _switching-between-yt-versions:
 
-Switching versions of yt: ``yt-2.x``, ``stable``, and ``master`` branches
+Switching versions of yt: ``yt-2.x``, ``stable``, and ``main`` branches
 -------------------------------------------------------------------------
 
 Here we explain how to switch between different development branches of yt.

doc/source/reference/changelog.rst

@@ -8,7 +8,7 @@ This is a non-comprehensive log of changes to yt over its many releases.
 Contributors
 ------------
 
-The `CREDITS file <https://github.com/yt-project/yt/blob/master/CREDITS>`_
+The `CREDITS file <https://github.com/yt-project/yt/blob/main/CREDITS>`_
 contains the most up-to-date list of everyone who has contributed to the yt
 source code.
 

doc/source/visualizing/unstructured_mesh_rendering.rst

@@ -22,7 +22,7 @@ To install yt with Embree support, you can install yt from source using the
 
 .. code-block:: bash
 
-  wget https://raw.githubusercontent.com/yt-project/yt/master/doc/install_script.sh
+  wget https://raw.githubusercontent.com/yt-project/yt/main/doc/install_script.sh
 
 and then run like so:
 

yt/funcs.py

@@ -584,19 +584,19 @@ def update_git(path):
             print("")
             print(f"    $ cd {path}")
             print("    $ git stash")
-            print("    $ git checkout master")
+            print("    $ git checkout main")
             print("    $ git pull")
             print("    $ git stash pop")
             print(f"    $ {sys.executable} setup.py develop")
             print("")
             return 1
-        if repo.active_branch.name != "master":
-            print("yt repository is not tracking the master branch so I won't ")
+        if repo.active_branch.name != "main":
+            print("yt repository is not tracking the main branch so I won't ")
             print("update the code. You will have to do this yourself.")
             print("Here's a set of sample commands:")
             print("")
             print(f"    $ cd {path}")
-            print("    $ git checkout master")
+            print("    $ git checkout main")
             print("    $ git pull")
             print(f"    $ {sys.executable} setup.py develop")
             print("")
@@ -611,9 +611,9 @@ def update_git(path):
                 "yt_upstream", url="https://github.com/yt-project/yt"
             )
             remote.fetch()
-        master = repo.heads.master
-        master.set_tracking_branch(remote.refs.master)
-        master.checkout()
+        main = repo.heads.main
+        main.set_tracking_branch(remote.refs.main)
+        main.checkout()
         remote.pull()
         new_version = repo.git.rev_parse("HEAD", short=12)
         f.write(f"Updated from {old_version} to {new_version}\n\n")
@@ -646,8 +646,8 @@ def update_hg(path):
         f.write("Updating the repository\n\n")
         books = repo.bookmarks()[0]
         books = [b[0].decode("utf8") for b in books]
-        if "master" in books:
-            repo.update("master", check=True)
+        if "main" in books:
+            repo.update("main", check=True)
         else:
             repo.update("yt", check=True)
         f.write(f"Updated from {ident} to {repo.identify()}\n\n")