From 57897b4095326d7e4433893f311f1aa2c4c8880c Mon Sep 17 00:00:00 2001 From: Jordan Justen Date: Mon, 26 Apr 2021 13:51:33 -0700 Subject: [PATCH] docs: Rename master branch to main Signed-off-by: Jordan Justen Reviewed-by: Eric Engestrom --- docs/ci/index.rst | 4 ++-- docs/drivers/vmware-guest.rst | 2 +- docs/helpwanted.rst | 2 +- docs/meson.rst | 2 +- docs/repository.rst | 26 +++++++++++++------------- docs/submittingpatches.rst | 10 +++++----- 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 `_ 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 `__ +- `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 `__ +`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 `__ as its source code management system. -The master Git repository is hosted on +The upstream Git repository is hosted on `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 ` -- 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