From 4a9d6583999898db2cdfe359f9ee64334d4787d8 Mon Sep 17 00:00:00 2001 From: Michael Schlottke-Lakemper Date: Fri, 29 Jan 2021 08:11:46 +0100 Subject: [PATCH] Rename all occurrences of `master` to `main` where it references our own repositories --- .github/workflows/Documenter.yml | 2 +- .github/workflows/ci.yml | 2 +- .outdated/.travis.yml | 4 ++-- .outdated/appveyor.yml | 2 +- README.md | 4 ++-- docs/src/github-git.md | 32 ++++++++++++++++---------------- docs/src/testing.md | 14 +++++++------- docs/src/visualization.md | 4 ++-- 8 files changed, 32 insertions(+), 32 deletions(-) diff --git a/.github/workflows/Documenter.yml b/.github/workflows/Documenter.yml index 828d10e0100..3af6956ac60 100644 --- a/.github/workflows/Documenter.yml +++ b/.github/workflows/Documenter.yml @@ -3,7 +3,7 @@ name: Documentation on: push: branches: - - master + - main tags: '*' pull_request: diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 042c9ef736e..948492495be 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -3,7 +3,7 @@ name: CI on: push: branches: - - master + - main paths-ignore: - 'AUTHORS.md' - 'CONTRIBUTING.md' diff --git a/.outdated/.travis.yml b/.outdated/.travis.yml index 09e599437ec..9ad906cbe4e 100644 --- a/.outdated/.travis.yml +++ b/.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 diff --git a/.outdated/appveyor.yml b/.outdated/appveyor.yml index a5e35ab0c8d..d8493416afd 100644 --- a/.outdated/appveyor.yml +++ b/.outdated/appveyor.yml @@ -17,7 +17,7 @@ platform: branches: only: - - master + - main - /release-.*/ # Do not build on tags (GitHub, Bitbucket, GitLab, Gitea) diff --git a/README.md b/README.md index 25e779acaca..e08a82e070b 100644 --- a/README.md +++ b/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) - +

diff --git a/docs/src/github-git.md b/docs/src/github-git.md index 70ee3acef1f..5648548164c 100644 --- a/docs/src/github-git.md +++ b/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 git@github.com: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 diff --git a/docs/src/testing.md b/docs/src/testing.md index 7accc981c67..89798ec10aa 100644 --- a/docs/src/testing.md +++ b/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%**. diff --git a/docs/src/visualization.md b/docs/src/visualization.md index fae95701f04..0d4712bbe04 100644 --- a/docs/src/visualization.md +++ b/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.