docs: Rename master branch to main
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Engestrom <eric@engestrom.ch>
This commit is contained in:
parent
2ec9cd3104
commit
57897b4095
|
@ -6,7 +6,7 @@ GitLab CI
|
||||||
|
|
||||||
GitLab provides a convenient framework for running commands in response to Git pushes.
|
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),
|
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,
|
(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
|
and even then the MR CI runs in the forked repository, which might have been
|
||||||
modified and thus is unreliable).
|
modified and thus is unreliable).
|
||||||
|
@ -175,7 +175,7 @@ branch, which can get tedious. Instead, you can navigate to the
|
||||||
`container registry
|
`container registry
|
||||||
<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`_ for
|
<https://gitlab.freedesktop.org/mesa/mesa/container_registry>`_ for
|
||||||
your repository and delete the tag to force a rebuild. When your code
|
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
|
(forks inherit images from the main repo, but MRs don't propagate
|
||||||
images from the fork into the main repo's registry).
|
images from the fork into the main repo's registry).
|
||||||
|
|
||||||
|
|
|
@ -106,7 +106,7 @@ Begin by saving your current directory location:
|
||||||
export TOP=$PWD
|
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
|
direct rendering svga driver for libGL, vmwgfx_dri.so, and the X
|
||||||
acceleration library libxatracker.so.x.x.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:**
|
**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.
|
- Status of OpenGL 3.x / 4.x features in Mesa.
|
||||||
|
|
||||||
**Legacy Driver specific To-Do lists:**
|
**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
|
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
|
for you. If that script doesn't work for some reason, you can always
|
||||||
look in the
|
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.
|
file at the root of the project.
|
||||||
|
|
||||||
With additional arguments ``meson configure`` can be used to change
|
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
|
Mesa uses `Git <https://git-scm.com>`__ as its source code management
|
||||||
system.
|
system.
|
||||||
|
|
||||||
The master Git repository is hosted on
|
The upstream Git repository is hosted on
|
||||||
`freedesktop.org <https://www.freedesktop.org>`__.
|
`freedesktop.org <https://www.freedesktop.org>`__.
|
||||||
|
|
||||||
You may access the repository either as an :ref:`anonymous
|
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
|
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
|
.. code-block:: console
|
||||||
|
|
||||||
|
@ -102,7 +102,7 @@ Development Branches
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
At any given time, there may be several active branches in Mesa's
|
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.
|
(unstable) code while a branch has the latest stable code.
|
||||||
|
|
||||||
The command ``git branch`` will list all available branches.
|
The command ``git branch`` will list all available branches.
|
||||||
|
@ -113,27 +113,27 @@ mailing list.
|
||||||
Developer Git Tips
|
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
|
If you try to do a pull by just saying\ ``git pull`` and Git
|
||||||
complains that you have not specified a branch, try:
|
complains that you have not specified a branch, try:
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
git config branch.master.remote origin
|
git config branch.main.remote origin
|
||||||
git config branch.master.merge master
|
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.
|
do a pull.
|
||||||
|
|
||||||
#. Small changes to master
|
#. Small changes to main
|
||||||
|
|
||||||
If you are an experienced Git user working on substantial
|
If you are an experienced Git user working on substantial
|
||||||
modifications, you are probably working on a separate branch and
|
modifications, you are probably working on a separate branch and
|
||||||
would rebase your branch prior to merging with master. But for small
|
would rebase your branch prior to merging with main. But for small
|
||||||
changes to the master branch itself, you also need to use the rebase
|
changes to the main branch itself, you also need to use the rebase
|
||||||
feature in order to avoid an unnecessary and distracting branch in
|
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
|
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
|
to get your changes ready to push back into the freedesktop.org
|
||||||
repository.
|
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
|
did your last pull. Even if your changes do not conflict with their
|
||||||
changes, Git will make a fast-forward merge branch, branching from
|
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
|
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
|
.. code-block:: console
|
||||||
|
|
||||||
git config branch.master.rebase true
|
git config branch.main.rebase true
|
||||||
git config --global branch.autosetuprebase=always
|
git config --global branch.autosetuprebase=always
|
||||||
|
|
||||||
See `Understanding Git
|
See `Understanding Git
|
||||||
|
|
|
@ -163,11 +163,11 @@ check for regressions.
|
||||||
As mentioned at the beginning, patches should be bisectable. A good way
|
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
|
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
|
tests on each commit. Assuming your branch is based off
|
||||||
``origin/master``, you can run:
|
``origin/main``, you can run:
|
||||||
|
|
||||||
.. code-block:: console
|
.. 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.
|
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
|
- Other tag examples: gallium, util
|
||||||
|
|
||||||
Tick the following when creating the MR. It allows developers to rebase
|
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.
|
broad discretion in rejecting patches that have been nominated.
|
||||||
|
|
||||||
- Patch must conform with the :ref:`Basic guidelines <guidelines>`
|
- 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
|
patch is too large and/or otherwise contradicts with the rules set
|
||||||
within, a backport is appropriate.
|
within, a backport is appropriate.
|
||||||
- It must not introduce a regression - be that build or runtime wise.
|
- 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.
|
de-nominate the patch.
|
||||||
|
|
||||||
For patches that either need to be nominated after they've landed in
|
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
|
stable branch (such as due to a rename), using a GitLab MR is most
|
||||||
appropriate. The MR should be based on and target the
|
appropriate. The MR should be based on and target the
|
||||||
staging/year.quarter branch, not on the year.quarter branch, per the
|
staging/year.quarter branch, not on the year.quarter branch, per the
|
||||||
|
|
Loading…
Reference in New Issue