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).
`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).
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.
**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:**
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
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
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
--------------------
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.
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
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
.. code-block:: console
- git config branch.master.rebase true
+ git config branch.main.rebase true
git config --global branch.autosetuprebase=always
See `Understanding Git
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.
- 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.
::
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.
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
projects / platform / upstream / mesa.git / commitdiff