docs: Rename master branch to main

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>

docs/ci/index.rst

@@ -6,7 +6,7 @@ GitLab CI
 
 GitLab provides a convenient framework for running commands in response to Git pushes.
 We use it to test merge requests (MRs) before merging them (pre-merge testing),
-as well as post-merge testing, for everything that hits ``master``
+as well as post-merge testing, for everything that hits ``main``
 (this is necessary because we still allow commits to be pushed outside of MRs,
 and even then the MR CI runs in the forked repository, which might have been
 modified and thus is unreliable).
@@ -175,7 +175,7 @@ branch, which can get tedious.  Instead, you can navigate to the
 `container registry
 <https://gitlab.freedesktop.org/mesa/mesa/container_registry>`_ for
 your repository and delete the tag to force a rebuild.  When your code
-is eventually merged to master, a full image rebuild will occur again
+is eventually merged to main, a full image rebuild will occur again
 (forks inherit images from the main repo, but MRs don't propagate
 images from the fork into the main repo's registry).
 

docs/drivers/vmware-guest.rst

@@ -106,7 +106,7 @@ Begin by saving your current directory location:
    export TOP=$PWD
      
 
--  Mesa/Gallium master branch. This code is used to build libGL, and the
+-  Mesa/Gallium main branch. This code is used to build libGL, and the
    direct rendering svga driver for libGL, vmwgfx_dri.so, and the X
    acceleration library libxatracker.so.x.x.x.
 

docs/helpwanted.rst

@@ -22,7 +22,7 @@ You can find some further To-do lists here:
 
 **Common To-Do lists:**
 
--  `features.txt <https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/docs/features.txt>`__
+-  `features.txt <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/features.txt>`__
    - Status of OpenGL 3.x / 4.x features in Mesa.
 
 **Legacy Driver specific To-Do lists:**

docs/meson.rst

@@ -109,7 +109,7 @@ running "meson build/" but this feature is being discussed upstream. For
 now, we have a ``bin/meson-options.py`` script that prints the options
 for you. If that script doesn't work for some reason, you can always
 look in the
-`meson_options.txt <https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/meson_options.txt>`__
+`meson_options.txt <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson_options.txt>`__
 file at the root of the project.
 
 With additional arguments ``meson configure`` can be used to change

docs/repository.rst

@@ -4,7 +4,7 @@ Source Code Repository
 Mesa uses `Git <https://git-scm.com>`__ as its source code management
 system.
 
-The master Git repository is hosted on
+The upstream Git repository is hosted on
 `freedesktop.org <https://www.freedesktop.org>`__.
 
 You may access the repository either as an :ref:`anonymous
@@ -30,7 +30,7 @@ To get the Mesa sources anonymously (read-only):
 
       git clone https://gitlab.freedesktop.org/mesa/mesa.git
 
-#. Later, you can update your tree from the master repository with:
+#. Later, you can update your tree from the upstream repository with:
 
    .. code-block:: console
 
@@ -102,7 +102,7 @@ Development Branches
 --------------------
 
 At any given time, there may be several active branches in Mesa's
-repository. Generally, ``master`` contains the latest development
+repository. Generally, ``main`` contains the latest development
 (unstable) code while a branch has the latest stable code.
 
 The command ``git branch`` will list all available branches.
@@ -113,27 +113,27 @@ mailing list.
 Developer Git Tips
 ------------------
 
-#. Setting up to edit the master branch
+#. Setting up to edit the main branch
 
    If you try to do a pull by just saying\ ``git pull`` and Git
    complains that you have not specified a branch, try:
 
    .. code-block:: console
 
-      git config branch.master.remote origin
-      git config branch.master.merge master
+      git config branch.main.remote origin
+      git config branch.main.merge main
 
-   Otherwise, you have to say\ ``git pull origin master`` each time you
+   Otherwise, you have to say\ ``git pull origin main`` each time you
    do a pull.
 
-#. Small changes to master
+#. Small changes to main
 
    If you are an experienced Git user working on substantial
    modifications, you are probably working on a separate branch and
-   would rebase your branch prior to merging with master. But for small
-   changes to the master branch itself, you also need to use the rebase
+   would rebase your branch prior to merging with main. But for small
+   changes to the main branch itself, you also need to use the rebase
    feature in order to avoid an unnecessary and distracting branch in
-   master.
+   main.
 
    If it has been awhile since you've done the initial clone, try
 
@@ -153,7 +153,7 @@ Developer Git Tips
    to get your changes ready to push back into the freedesktop.org
    repository.
 
-   It is possible (and likely) that someone has changed master since you
+   It is possible (and likely) that someone has changed main since you
    did your last pull. Even if your changes do not conflict with their
    changes, Git will make a fast-forward merge branch, branching from
    the point in time where you did your last pull and merging it to a
@@ -183,7 +183,7 @@ Developer Git Tips
 
    .. code-block:: console
 
-      git config branch.master.rebase true
+      git config branch.main.rebase true
       git config --global branch.autosetuprebase=always
 
    See `Understanding Git

docs/submittingpatches.rst

@@ -163,11 +163,11 @@ check for regressions.
 As mentioned at the beginning, patches should be bisectable. A good way
 to test this is to make use of the \`git rebase\` command, to run your
 tests on each commit. Assuming your branch is based off
-``origin/master``, you can run:
+``origin/main``, you can run:
 
 .. code-block:: console
 
-   $ git rebase --interactive --exec "meson test -C build/" origin/master
+   $ git rebase --interactive --exec "meson test -C build/" origin/main
 
 replacing ``"meson test"`` with whatever other test you want to run.
 
@@ -188,7 +188,7 @@ Add labels to your MR to help reviewers find it. For example:
 -  Other tag examples: gallium, util
 
 Tick the following when creating the MR. It allows developers to rebase
-your work on top of master.
+your work on top of main.
 
 ::
 
@@ -304,7 +304,7 @@ accepted and which are not. The stable-release manager is also given
 broad discretion in rejecting patches that have been nominated.
 
 -  Patch must conform with the :ref:`Basic guidelines <guidelines>`
--  Patch must have landed in master first. In case where the original
+-  Patch must have landed in main first. In case where the original
    patch is too large and/or otherwise contradicts with the rules set
    within, a backport is appropriate.
 -  It must not introduce a regression - be that build or runtime wise.
@@ -353,7 +353,7 @@ conflicts they should ask the original author to provide a backport or
 de-nominate the patch.
 
 For patches that either need to be nominated after they've landed in
-master, or that are known ahead of time to not not apply cleanly to a
+main, or that are known ahead of time to not not apply cleanly to a
 stable branch (such as due to a rename), using a GitLab MR is most
 appropriate. The MR should be based on and target the
 staging/year.quarter branch, not on the year.quarter branch, per the