Verified Commit 57897b40 authored by Jordan Justen's avatar Jordan Justen
Browse files

docs: Rename master branch to main


Signed-off-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Engestrom's avatarEric Engestrom <eric@engestrom.ch>
parent 2ec9cd31
......@@ -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).
......
......@@ -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.
......
......@@ -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:**
......
......@@ -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
......
......@@ -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
......
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment