Rename all occurrences of master to main where it references our …

…own repositories

.github/workflows/Documenter.yml

@@ -3,7 +3,7 @@ name: Documentation
 on:
   push:
     branches:
-      - master
+      - main
     tags: '*'
   pull_request:
 

.github/workflows/ci.yml

@@ -3,7 +3,7 @@ name: CI
 on:
   push:
     branches:
-      - master
+      - main
     paths-ignore:
       - 'AUTHORS.md'
       - 'CONTRIBUTING.md'

.outdated/.travis.yml

@@ -13,7 +13,7 @@ jobs:
   allow_failures:
     - julia: nightly
   include:
-    - if: type = push AND branch = master
+    - if: type = push AND branch = main
       julia: 1
       os: osx
     # - stage: "Documentation"
@@ -51,7 +51,7 @@ codecov: true
 # avoid duplicate tests in PRs
 branches:
   only:
-    - master
+    - main
     - dev
 
 # we could use groups to trigger multiple builds in parallel to speed-up running expensive tests

.outdated/appveyor.yml

@@ -17,7 +17,7 @@ platform:
 
 branches:
   only:
-    - master
+    - main
     - /release-.*/
 
 # Do not build on tags (GitHub, Bitbucket, GitLab, Gitea)

README.md

@@ -3,12 +3,12 @@
 [![Docs-stable](https://img.shields.io/badge/docs-stable-blue.svg)](https://trixi-framework.github.io/Trixi.jl/stable)
 [![Docs-dev](https://img.shields.io/badge/docs-dev-blue.svg)](https://trixi-framework.github.io/Trixi.jl/dev)
 [![Build Status](https://github.com/trixi-framework/Trixi.jl/workflows/CI/badge.svg)](https://github.com/trixi-framework/Trixi.jl/actions?query=workflow%3ACI)
-[![Coveralls](https://coveralls.io/repos/github/trixi-framework/Trixi.jl/badge.svg?branch=master)](https://coveralls.io/github/trixi-framework/Trixi.jl?branch=master)
+[![Coveralls](https://coveralls.io/repos/github/trixi-framework/Trixi.jl/badge.svg?branch=main)](https://coveralls.io/github/trixi-framework/Trixi.jl?branch=main)
 [![License: MIT](https://img.shields.io/badge/License-MIT-success.svg)](https://opensource.org/licenses/MIT)
 [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.3996439.svg)](https://doi.org/10.5281/zenodo.3996439)
 [![GitHub commits since tagged version](https://img.shields.io/github/commits-since/trixi-framework/Trixi.jl/v0.3.13.svg?style=social&logo=github)](https://github.com/trixi-framework/Trixi.jl)
 <!-- [![PkgEval](https://juliaci.github.io/NanosoldierReports/pkgeval_badges/T/Trixi.svg)](https://juliaci.github.io/NanosoldierReports/pkgeval_badges/report.html) -->
-<!-- [![Codecov](https://codecov.io/gh/trixi-framework/Trixi.jl/branch/master/graph/badge.svg)](https://codecov.io/gh/trixi-framework/Trixi.jl) -->
+<!-- [![Codecov](https://codecov.io/gh/trixi-framework/Trixi.jl/branch/main/graph/badge.svg)](https://codecov.io/gh/trixi-framework/Trixi.jl) -->
 
 <p align="center">
   <img width="300px" src="docs/src/assets/logo.png">

docs/src/github-git.md

@@ -17,7 +17,7 @@ the reasons for a particular choice of implementation or feature.
 
 ### Create a branch and *immediately* create a pull request
 All feature development, bug fixes etc. should be developed in a branch and not
-directly on `master`. If you do not have write access to the main repository on
+directly on `main`. If you do not have write access to the main repository on
 GitHub, first create a fork of the Trixi.jl repository and clone the fork to
 your machine. Then, create a branch locally by executing `git checkout -b
 yourbranch`, push it to the repository, and create a pull request (PR).
@@ -27,8 +27,8 @@ you can also work in that clone. You just need to add your fork as additional
 remote repository and push your new branch there.
 ```bash
 git remote add myfork [email protected]:YOUR_NAME/Trixi.jl.git
-# get latest master from the main repo
-git checkout master
+# get latest main from the main repo
+git checkout main
 git pull
 # create a new branch for a cool new feature, bug fix, ...
 git checkout -b YOUR_BRANCH_NAME
@@ -42,7 +42,7 @@ git push -u myfork
     Immediately creating a PR for your branch has the benefit that all
     code discussions can now be held directly next to the corresponding code. Also,
     the PR allows to easily compare your branch to the upstream branch
-    (usually `master`) to see what you have changed. Moreover, tests will run
+    (usually `main`) to see what you have changed. Moreover, tests will run
     automatically.
 
 ### Make changes
@@ -60,32 +60,32 @@ changes or dive in and change something themselves.
     pushed your changes**. If you *did* push your changes, please talk to one of
     the core developers on how to proceed.
 
-### Keep your branch in sync with `master`
+### Keep your branch in sync with `main`
 For larger features with longer-living branches, it may make sense to
-synchronize your branch with the current `master`, e.g., if there was a bug fix
-in `master` that is relevant for you. In this case, perform the following steps to
-merge the current `master` to your branch:
+synchronize your branch with the current `main`, e.g., if there was a bug fix
+in `main` that is relevant for you. In this case, perform the following steps to
+merge the current `main` to your branch:
 
   1. Commit all your local changes to your branch and push it. This allows you to
      delete your clone in case you make a mistake and need to abort the merge.
   2. Execute `git fetch` to get the latest changes from the repository.
   3. Make sure you are in the correct branch by checking the output of `git
      status` or by running `git checkout yourbranch`.
-  4. Merge master using `git merge master`. If there were no conflicts, hooray!,
+  4. Merge main using `git merge main`. If there were no conflicts, hooray!,
      you are done. Otherwise you need to resolve your merge conflicts and commit
      the changes afterwards. A good guide for resolving merge conflicts can be
      found
      [here](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-using-the-command-line).
 
 In general, always use `git merge` and not `git rebase` to get the latest
-changes from `master`. It is less error-prone and does not create problems on
+changes from `main`. It is less error-prone and does not create problems on
 branches that are worked on collaboratively.
 
 ### Prepare for review
-If you feel like your branch is ready to be merged to master, prepare it for
+If you feel like your branch is ready to be merged to main, prepare it for
 review. That is, you should
 
-  * merge the current `master` to your branch
+  * merge the current `main` to your branch
   * run tests if available, but at least ensure that you did not accidentally
     change the results for one of the existing example elixirs
   * properly comment your code
@@ -110,7 +110,7 @@ branch, and the corresponding pull request will be updated automatically.
 
 Please note that a review has nothing to do with the lack of experience of the
 person developing changes: We try to review all code before it gets added to
-`master`, even from the most experienced developers. This is good practice and
+`main`, even from the most experienced developers. This is good practice and
 helps to keep the error rate low while ensuring the the code is developed in a
 consistent fashion. Furthermore, do not take criticism of your code personally -
 we just try to keep Trixi as accessible and easy to use for everyone.
@@ -121,7 +121,7 @@ make sure that all the latest changes have been pushed. Then, one of the
 developers will merge your PR. If you are one of the developers, you can also go
 to the pull request page on GitHub and and click on **Merge pull request**.
 Voilá, you are done! Your branch will have been merged to
-`master` and the source branch will have been deleted in the GitHub repository
+`main` and the source branch will have been deleted in the GitHub repository
 (if you are not working in your own fork).
 
 ### Update your working copy
@@ -130,7 +130,7 @@ should clean up your local working copy of the repository by performing the
 following steps:
 
   1. Update your clone by running `git fetch`.
-  2. Check out `master` using `git checkout master`.
+  2. Check out `main` using `git checkout main`.
   3. Delete merged branch locally with `git branch -d yourbranch`.
   4. Remove local references to deleted remote branch by executing `git remote
      prune origin`.
@@ -179,7 +179,7 @@ the following steps need to be taken (as documented for GitLab in issue
 
   1. Tell everyone to commit and push their changes to the repository.
   2. Fix the branch in which the file was committed by removing it and committing
-     the removal. This is especially important on `master`.
+     the removal. This is especially important on `main`.
   3. Perform the following steps to clean up the Git repository:
      ```bash
      cd /tmp

docs/src/testing.md

@@ -9,22 +9,22 @@ repositories for the visualization tools [Trixi2Img](https://github.com/trixi-fr
 [GitHub Actions](https://docs.github.com/en/free-pro-team@latest/actions),
 which allows to run tests automatically upon certain events. When, how, and what
 is tested by GitHub Actions is controlled by the workflow file
-[`.github/workflows/ci.yml`](https://github.com/trixi-framework/Trixi.jl/blob/master/.github/workflows/ci.yml).
+[`.github/workflows/ci.yml`](https://github.com/trixi-framework/Trixi.jl/blob/main/.github/workflows/ci.yml).
 In Trixi and its related repositories, tests are triggered by
-* each `git push` to `master` and
+* each `git push` to `main` and
 * each `git push` to any pull request.
 Besides checking functionality, we also analyse the [Test coverage](@ref) to
 ensure that we do not miss important parts during testing.
 
 !!! note "Test and coverage requirements"
-    Before merging a pull request (PR) to `master`, we require that
+    Before merging a pull request (PR) to `main`, we require that
     * the code passes all functional tests
     * code coverage does not decrease.
 
 
 ## Testing setup
 The entry point for all testing is the file
-[`test/runtests.jl`](https://github.com/trixi-framework/Trixi.jl/blob/master/test/runtests.jl),
+[`test/runtests.jl`](https://github.com/trixi-framework/Trixi.jl/blob/main/test/runtests.jl),
 which is run by the automated tests and which can be triggered manually by
 executing
 ```julia
@@ -42,7 +42,7 @@ julia> include(joinpath("test", "test_examples_2d_euler.jl")) # Run only 2D test
 For the automated tests with GitHub Actions, we run multiple jobs in parallel to
 reduce the waiting time until all tests are finished. You can see the different
 components that are run as jobs by looking at the `TRIXI_TEST` variable in
-[`test/runtests.jl`](https://github.com/trixi-framework/Trixi.jl/blob/master/test/runtests.jl).
+[`test/runtests.jl`](https://github.com/trixi-framework/Trixi.jl/blob/main/test/runtests.jl).
 
 
 ## Adding new tests
@@ -52,7 +52,7 @@ test, and all new elixirs added to the `examples/` directory must be used at
 least once during testing. New tests should be added to the corresponding
 `test/test_xxx.jl` file, e.g., a test involving the 3D linear advection equation
 would go into
-[`test/test_examples_3d_advection.jl`](https://github.com/trixi-framework/Trixi.jl/blob/master/test/test_examples_3d_advection.jl).
+[`test/test_examples_3d_advection.jl`](https://github.com/trixi-framework/Trixi.jl/blob/main/test/test_examples_3d_advection.jl).
 Please study one of the existing tests and stay consistent to the current style
 when creating new tests.
 
@@ -83,4 +83,4 @@ which *new* lines the pull requests adds to Trixi's code base that are not yet
 covered by testing.
 !!! note "Coverage requirements"
     In general, we require pull requests to *not decrease* the overall
-    test coverage percentage in `master`, with a **hard lower bound of 97%**.
+    test coverage percentage in `main`, with a **hard lower bound of 97%**.

docs/src/visualization.md

@@ -184,7 +184,7 @@ discontinuous Galerkin solution data while `solution_000000_celldata.vtu` holds
 any cell-based values such as the current AMR indicator or the cell refinement
 level.
 
-!["solution_000000_scalar_mesh"](https://github.com/trixi-framework/Trixi2Vtk.jl/raw/master/docs/src/assets/solution_000000_scalar_mesh.png)
+!["solution_000000_scalar_mesh"](https://github.com/trixi-framework/Trixi2Vtk.jl/raw/main/docs/src/assets/solution_000000_scalar_mesh.png)
 
 This allows you to generate VTK files for solution, restart and mesh files. By
 default, Trixi2Vtk generates `.vtu` (unstructured VTK) files for both
@@ -247,7 +247,7 @@ julia> trixi2img(joinpath("out", "solution_000040.h5"), output_directory="out",
 This will create a file `solution_000040_scalar.png` in the `out/` subdirectory
 that can be opened with any image viewer:
 
-!["solution_000040_scalar_resized"](https://github.com/trixi-framework/Trixi2Img.jl/raw/master/docs/src/assets/solution_000040_scalar_resized.png)
+!["solution_000040_scalar_resized"](https://github.com/trixi-framework/Trixi2Img.jl/raw/main/docs/src/assets/solution_000040_scalar_resized.png)
 
 To visualize 3D data generated by Trixi.jl, a 2D slice must be extracted.
 A slice can only lie in a plane orthogonal to one of the coordinate axes.