summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJordan Justen <jordan.l.justen@intel.com>2021-04-26 13:51:33 -0700
committerJordan Justen <jordan.l.justen@intel.com>2021-05-05 12:21:00 -0700
commit57897b4095326d7e4433893f311f1aa2c4c8880c (patch)
tree536b9a1d144193850f423a28f4de2847b946038e
parent2ec9cd31042a0c994c42a024c9185a7fcccf9855 (diff)
docs: Rename master branch to main
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Engestrom <eric@engestrom.ch>
-rw-r--r--docs/ci/index.rst4
-rw-r--r--docs/drivers/vmware-guest.rst2
-rw-r--r--docs/helpwanted.rst2
-rw-r--r--docs/meson.rst2
-rw-r--r--docs/repository.rst26
-rw-r--r--docs/submittingpatches.rst10
6 files changed, 23 insertions, 23 deletions
diff --git a/docs/ci/index.rst b/docs/ci/index.rst
index 009fdf37075..b69c12f26d8 100644
--- a/docs/ci/index.rst
+++ b/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).
diff --git a/docs/drivers/vmware-guest.rst b/docs/drivers/vmware-guest.rst
index 6987698b064..df9e09e411d 100644
--- a/docs/drivers/vmware-guest.rst
+++ b/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.
diff --git a/docs/helpwanted.rst b/docs/helpwanted.rst
index 75e5a0c90c9..8ed54345538 100644
--- a/docs/helpwanted.rst
+++ b/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:**
diff --git a/docs/meson.rst b/docs/meson.rst
index 8e04eb313b1..f7b9d5a876d 100644
--- a/docs/meson.rst
+++ b/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
diff --git a/docs/repository.rst b/docs/repository.rst
index 9eff2ae8a8e..52645ffb904 100644
--- a/docs/repository.rst
+++ b/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
diff --git a/docs/submittingpatches.rst b/docs/submittingpatches.rst
index d19c7a8d7a9..9dd3150295e 100644
--- a/docs/submittingpatches.rst
+++ b/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