Update docs with 'main' as the primary branch (#1782)

CONTRIBUTING.md

@@ -18,7 +18,7 @@ We actively welcome pull requests.
 
 1. Prior to investing a large amount of time into significant or invasive changes, or those that affect the output, it is likely more efficient to first open an issue for discussion and planning.
 2. If you are not familiar with the project, focus first on the [Good first issues](https://github.com/ocaml-ppx/ocamlformat/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22Good-first-issue+%3A%2B1%3A%22).
-3. Fork the repository and create your branch from `master`.
+3. Fork the repository and create your branch from `main`.
 4. If you have added code that should be tested, add tests (they should be located in the `tests/passing` directory).
 '.
 5. Ensure the test suite passes (see [Running the tests](#running-the-tests)).
@@ -37,7 +37,7 @@ The second part of `make test` is to ensure the test suite passes. You should no
 
 Once `make test` passes, pull requests should be tested on the code in a set of external repositories. This can be done by executing `tools/test_branch.sh <rev>` where `<rev>` is the git revision/branch containing the pull request's changes. If a pull request affects an option, `OCAMLFORMAT=<option>=<value> tools/test_branch.sh <rev>` should also be run to test with the option enabled.
 
-The `tools/test_branch.sh` script runs two versions of `ocamlformat` (the specified branch, or `HEAD` if omitted, and its merge base with master) on the test code and reports the differences in the formatted code. Formatting failures may also be reported on the terminal, these will need to be fixed before a pull request can be merged. The differences should be inspected to ensure they are as intended. Pull requests changing the format of code should generally introduce an option to enable the alternate style (if in doubt, open an issue for discussion). Any differences in the formatted code with the option disabled should be summarized and explained in the pull request discussion.
+The `tools/test_branch.sh` script runs two versions of `ocamlformat` (the specified branch, or `HEAD` if omitted, and its merge base with main) on the test code and reports the differences in the formatted code. Formatting failures may also be reported on the terminal, these will need to be fixed before a pull request can be merged. The differences should be inspected to ensure they are as intended. Pull requests changing the format of code should generally introduce an option to enable the alternate style (if in doubt, open an issue for discussion). Any differences in the formatted code with the option disabled should be summarized and explained in the pull request discussion.
 
 To benefit from the autocompletion of git branch names in the `tools/test_branch.sh` script, if you use the `bash` shell, add the following line to your `~/.bashrc` file:
 ```

HACKING.org

@@ -43,7 +43,7 @@ Git is used to manage the script's state:
 
 - Release in automatic mode
   =dune-release=
-  Until dune-release.1.5.0 is released the =master= branch of dune-release
+  Until dune-release.1.5.0 is released the =main= branch of dune-release
   should be used.
 
 - Close release milestone.
@@ -75,26 +75,26 @@ Git is used to manage the script's state:
 
 * Backporting changes to a point release
 
-Sometimes it is helpful to create a point release, but master contains
+Sometimes it is helpful to create a point release, but main contains
 changes that would be unsuitable for a point release.
 
-Suppose the last release is 0.3.5, and since then, master contains new
+Suppose the last release is 0.3.5, and since then, main contains new
 features F1 and F2 and a bugfix B.
 
 #+BEGIN_SRC
 release 0.3.5 -> feature F1 -> bugfix B -> feature F2
-tag: 0.3.5                                 branch: master
+tag: 0.3.5                                 branch: main
 #+END_SRC
 
-Instead of reverting F1 and F2 in master, one can create a release branch for
+Instead of reverting F1 and F2 in main, one can create a release branch for
 the 0.3 releases.
 
 The end graph looks like this (if this is the first point release done this
 way in the 0.3.x series):
 
 #+BEGIN_SRC
 release 0.3.5 -> feature F1 -> bugfix B -> feature F2 -> merge commit
-tag: 0.3.5                                               branch: master
+tag: 0.3.5                                               branch: main
             \                                          /
               -> bugfix B -> release 0.3.6  ----------
                              tag: 0.3.6
@@ -105,16 +105,16 @@ Or (if a previous point release has been made in the same way):
 
 #+BEGIN_SRC
  past  ->  merge commit -> feature F1 -> bugfix B -> feature F2 -> merge commit
-               /                                       branch: master
+               /                                       branch: main
               /                                       /
  release 0.3.5  -> bugfix B -> release 0.3.6  -------
  tag: 0.3.5                    tag: 0.3.6
                                branch: 0.3
 #+END_SRC
 
 Notes:
-- the release branch is always merged into master, not the other way around.
-- version detection relies on git tags, so master will be marked 0.3.5-x
+- the release branch is always merged into main, not the other way around.
+- version detection relies on git tags, so main will be marked 0.3.5-x
   before the merge and 0.3.6-x after.
 
 ** Step 1: prepare release branch
@@ -132,7 +132,7 @@ Notes:
   + These may not apply cleanly, so fix conflicts and QA (using CI, etc) as usual.
   + For the changelog in particular, the entry for the bugfix should go in a new section, and new features should not appear.
 
-Changelog in master:
+Changelog in main:
 
 #+BEGIN_SRC
 ### unreleased
@@ -171,13 +171,13 @@ Changelog in 0.3 release branch:
 
 - Wait for opam-repository PR to be merged.
 
-- Merge release branch into master.
+- Merge release branch into main.
   + Not as a PR; as a manual merge.
-  + Example: =git checkout master= followed by =git merge 0.3=.
+  + Example: =git checkout main= followed by =git merge 0.3=.
   + This may conflict, in particular in the changelog.
-  + To resolve the changelog conflict, add the point release section into master, and remove backported entries from the unreleased section.
+  + To resolve the changelog conflict, add the point release section into main, and remove backported entries from the unreleased section.
 
-Changelog in master before merging:
+Changelog in main before merging:
 
 #+BEGIN_SRC
 ### unreleased

README.md

@@ -1,4 +1,4 @@
-[![Build Status](https://img.shields.io/endpoint?url=https%3A%2F%2Fci.ocamllabs.io%2Fbadge%2Focaml-ppx%2Focamlformat%2Fmaster&logo=ocaml)](https://ci.ocamllabs.io/github/ocaml-ppx/ocamlformat)
+[![Build Status](https://img.shields.io/endpoint?url=https%3A%2F%2Fci.ocamllabs.io%2Fbadge%2Focaml-ppx%2Focamlformat%2Fmain&logo=ocaml)](https://ci.ocamllabs.io/github/ocaml-ppx/ocamlformat)
 
 # OCamlFormat
 

tools/test_branch.sh

@@ -14,7 +14,7 @@
 # usage: test_branch.sh [-a=rev] [-b=rev] [<option>=<value>*] [<option>=<value>*]
 #
 # -a set the base branch and -b the test branch. The default value for
-# the base branch is the merge-base between the test branch and master.
+# the base branch is the merge-base between the test branch and main.
 # The default value for the test branch is HEAD.
 #
 # The first arg is the value of OCAMLFORMAT to be used when formatting
@@ -41,7 +41,7 @@ opts_a=$1
 opts_b=${2-$opts_a}
 
 rev_b=$(git rev-parse "${arg_b:-HEAD}")
-rev_a=$(git rev-parse "${arg_a:-$(git merge-base master "$rev_b")}")
+rev_a=$(git rev-parse "${arg_a:-$(git merge-base main "$rev_b")}")
 
 if [[ "$rev_a" = "$rev_b" ]]; then
   echo "The base branch is the same as the branch to test ($rev_a)"