[docs] Inclusive language: replace master with main

[quinnp]

Summary

[NFC] As part of using inclusive language within the llvm
project and be consistent with the renamed branch,
replace master with main.

[mehdi_amini]

Thanks. Do you need someone to land this for you?

[quinnp]

In D112746#3095365, @mehdi_amini wrote:

Thanks. Do you need someone to land this for you?

Thanks for accepting, I can land this.

llvm/docs/Proposals/GitHubMove.rst

 - "Sequential IDs are important for LNT and llvmlab bisection tool." [MatthewsRevNum]_.
 
 However, Git can emulate this increasing revision number:
 ``git rev-list --count <commit-hash>``. This identifier is unique only
 within a single branch, but this means the tuple `(num, branch-name)` uniquely
 identifies a commit.
 
 We can thus use this revision number to ensure that e.g. `clang -v` reports a
-user-friendly revision number (e.g. `master-12345` or `4.0-5321`), addressing
+user-friendly revision number (e.g. `main-12345` or `4.0-5321`), addressing
 the objections raised above with respect to this aspect of Git.
 
 What About Branches and Merges?
 -------------------------------
 
 In contrast to SVN, Git makes branching easy. Git's commit history is
 represented as a DAG, a departure from SVN's linear history. However, we propose
 to mandate making merge commits illegal in our canonical Git repository.

 ::
 
   # direct SVN checkout
   svn co https://[e-mail]/svn/llvm-project/llvm/trunk llvm
   # or using the read-only Git view, with git-svn
   git clone https://llvm.org/git/llvm.git
   cd llvm
   git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
-  git config svn-remote.svn.fetch :refs/remotes/origin/master
+  git config svn-remote.svn.fetch :refs/remotes/origin/main
   git svn rebase -l  # -l avoids fetching ahead of the git mirror.
 
 Commits are performed using `svn commit` or with the sequence `git commit` and
 `git svn dcommit`.
 
 .. _workflow-multicheckout-nocommit:
 
 Monorepo Variant

 
 Note that when you fetch you'll likely pull in changes to sub-projects you don't
 care about. If you are using sparse checkout, the files from other projects
 won't appear on your disk. The only effect is that your commit hash changes.
 
 You can check whether the changes in the last fetch are relevant to your commit
 by running::
 
-  git log origin/master@{1}..origin/master -- libcxx
+  git log origin/main@{1}..origin/main -- libcxx
 
 This command can be hidden in a script so that `git llvmpush` would perform all
 these steps, fail only if such a dependent change exists, and show immediately
 the change that prevented the push. An immediate repeat of the command would
 (almost) certainly result in a successful push.
 Note that today with SVN or git-svn, this step is not possible since the
 "rebase" implicitly happens while committing (unless a conflict occurs).
 
::
   cd ../projects
   svn co https://llvm.org/svn/llvm-project/libcxx/trunk libcxx -r $REVISION
 
 Or using git-svn::
 
   git clone https://llvm.org/git/llvm.git
   cd llvm/
   git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
-  git config svn-remote.svn.fetch :refs/remotes/origin/master
+  git config svn-remote.svn.fetch :refs/remotes/origin/main
   git svn rebase -l
   git checkout `git svn find-rev -B r258109`
   cd tools
   git clone https://llvm.org/git/clang.git
   cd clang/
   git svn init https://llvm.org/svn/llvm-project/clang/trunk --username=<username>
-  git config svn-remote.svn.fetch :refs/remotes/origin/master
+  git config svn-remote.svn.fetch :refs/remotes/origin/main
   git svn rebase -l
   git checkout `git svn find-rev -B r258109`
   cd ../../projects/
   git clone https://llvm.org/git/libcxx.git
   cd libcxx
   git svn init https://llvm.org/svn/llvm-project/libcxx/trunk --username=<username>
-  git config svn-remote.svn.fetch :refs/remotes/origin/master
+  git config svn-remote.svn.fetch :refs/remotes/origin/main
   git svn rebase -l
   git checkout `git svn find-rev -B r258109`
 
 Note that the list would be longer with more sub-projects.
 
 .. _workflow-monocheckout-multicommit:
 
 Monorepo Variant
migrate-downstream-fork.py \
        --new-repo-prefix=refs/remotes/upstream/monorepo \
        --old-repo-prefix=refs/remotes/upstream/split \
        --source-kind=split \
        --revmap-out=monorepo-map.txt
   )
 
   # Octopus-merge the resulting local split histories to unify them.
 
-  # Assumes local work on local split mirrors is on master (and
+  # Assumes local work on local split mirrors is on main (and
   # upstream is presumably represented by some other branch like
-  # upstream/master).
-  my_local_branch="master"
+  # upstream/main).
+  my_local_branch="main"
 
-  git -C my-monorepo branch --no-track local/octopus/master \
-    $(git -C my-monorepo merge-base refs/remotes/upstream/monorepo/master \
+  git -C my-monorepo branch --no-track local/octopus/main \
+    $(git -C my-monorepo merge-base refs/remotes/upstream/monorepo/main \
                                     refs/remotes/local/split/llvm/${my_local_branch})
   git -C my-monorepo checkout local/octopus/${my_local_branch}
 
   subproject_branches=()
   for p in ${my_projects[@]}; do
     subproject_branch=${p}/local/monorepo/${my_local_branch}
     git -C my-monorepo branch ${subproject_branch} \
       refs/remotes/local/split/${p}/${my_local_branch}
Python script and are expanded on below to a more general recipe::
   for ref in $(git -C my-monorepo for-each-ref --format="%(refname)" \
                    refs/remotes/upstream/monorepo); do
     upstream_branch=${ref#refs/remotes/upstream/monorepo/}
     git -C my-monorepo branch upstream/${upstream_branch} ${ref}
   done
 
 The above gets you to a state like the following::
 
-  U1 - U2 - U3 <- upstream/master
+  U1 - U2 - U3 <- upstream/main
     \   \    \
      \   \    - Llld1 - Llld2 -
       \   \                    \
-       \   - Lclang1 - Lclang2-- Lmerge <- local/octopus/master
+       \   - Lclang1 - Lclang2-- Lmerge <- local/octopus/main
         \                      /
          - Lllvm1 - Lllvm2-----
 
 Each branched component has its branch rewritten on top of the
 monorepo and all components are unified by a giant octopus merge.
 
 If additional active local branches need to be preserved, the above
 operations following the assignment to ``my_local_branch`` should be

 through the history of one component leaves the other components fixed
 at a history that likely makes things unbuildable.
 
 Some downstream users track the order commits were made to subprojects
 with some kind of "umbrella" project that imports the project git
 mirrors as submodules, similar to the multirepo umbrella proposed
 above.  Such an umbrella repository looks something like this::
 
-   UM1 ---- UM2 -- UM3 -- UM4 ---- UM5 ---- UM6 ---- UM7 ---- UM8 <- master
+   UM1 ---- UM2 -- UM3 -- UM4 ---- UM5 ---- UM6 ---- UM7 ---- UM8 <- main
    |        |             |        |        |        |        |
   Lllvm1   Llld1         Lclang1  Lclang2  Lllvm2   Llld2     Lmyproj1
 
 The vertical bars represent submodule updates to a particular local
 commit in the project mirror.  ``UM3`` in this case is a commit of
 some local umbrella repository state that is not a submodule update,
 perhaps a ``README`` or project build script update.  Commit ``UM8``
 updates a submodule of local project ``myproj``.
 
 The tool ``zip-downstream-fork.py`` at
 https://github.com/greened/llvm-git-migration/tree/zip can be used to
 convert the umbrella history into a monorepo-based history with
 commits in the order implied by submodule updates::
 
-  U1 - U2 - U3 <- upstream/master
+  U1 - U2 - U3 <- upstream/main
    \    \    \
     \    -----\---------------                                    local/zip--.
      \         \              \                                               |
     - Lllvm1 - Llld1 - UM3 -  Lclang1 - Lclang2 - Lllvm2 - Llld2 - Lmyproj1 <-'
 
 
-The ``U*`` commits represent upstream commits to the monorepo master
+The ``U*`` commits represent upstream commits to the monorepo main
 branch.  Each submodule update in the local ``UM*`` commits brought in
 a subproject tree at some local commit.  The trees in the ``L*1``
 commits represent merges from upstream.  These result in edges from
 the ``U*`` commits to their corresponding rewritten ``L*1`` commits.
 The ``L*2`` commits did not do any merges from upstream.
 
 Note that the merge from ``U2`` to ``Lclang1`` appears redundant, but
 if, say, ``U3`` changed some files in upstream clang, the ``Lclang1``
zip-downstream-fork.py \
       --old-repo-prefix=refs/remotes/upstream/split \
       --revmap-in=monorepo-map.txt \
       --revmap-out=zip-map.txt \
       --subdir=local \
       --submodule-map=submodule-map.txt \
       --update-tags
    )
 
-   # Create the zip branch (assuming umbrella master is wanted).
-   git -C my-monorepo branch --no-track local/zip/master refs/remotes/umbrella/master
+   # Create the zip branch (assuming umbrella main is wanted).
+   git -C my-monorepo branch --no-track local/zip/main refs/remotes/umbrella/main
 
 Note that if the umbrella has submodules to non-LLVM repositories,
 ``zip-downstream-fork.py`` needs to know about them to be able to
 rewrite commits.  That is why the first step above is to fetch commits
 from such repositories.
 
 With ``--update-tags`` the tool will migrate annotated tags pointing
 to submodule commits that were inlined into the zipped history.  If
zip-downstream-fork.py \
       --old-repo-prefix=refs/remotes/upstream/split \
       --revmap-in=monorepo-map.txt \
       --revmap-out=zip-map.txt \
       --subdir=llvm \
       --submodule-map=submodule-map.txt \
       --update-tags
    )
 
-   # Create the zip branch (assuming umbrella master is wanted).
-   git -C my-monorepo branch --no-track local/zip/master refs/remotes/umbrella/master
+   # Create the zip branch (assuming umbrella main is wanted).
+   git -C my-monorepo branch --no-track local/zip/main refs/remotes/umbrella/main
 
 
 Comments at the top of ``zip-downstream-fork.py`` describe in more
 detail how the tool works and various implications of its operation.
 
 Importing local repositories
 ----------------------------
 
getting them into the monorepo.  A recipe follows::
 
    # Preserve release branches.
    for ref in $(git -C my-monorepo for-each-ref --format="%(refname)" \
                   refs/remotes/myrepo/release); do
      branch=${ref#refs/remotes/myrepo/}
      git -C my-monorepo branch --no-track myrepo/${branch} ${ref}
    done
 
-   # Preserve master.
-   git -C my-monorepo branch --no-track myrepo/master refs/remotes/myrepo/master
+   # Preserve main.
+   git -C my-monorepo branch --no-track myrepo/main refs/remotes/myrepo/main
 
-   # Merge master.
-   git -C my-monorepo checkout local/zip/master  # Or local/octopus/master
-   git -C my-monorepo merge myrepo/master
+   # Merge main.
+   git -C my-monorepo checkout local/zip/main  # Or local/octopus/main
+   git -C my-monorepo merge myrepo/main
 
 You may want to merge other corresponding branches, for example
 ``myrepo`` release branches if they were in lockstep with LLVM project
 releases.
 
 ``--tag-prefix`` tells ``import-downstream-repo.py`` to rename
 annotated tags with the given prefix.  Due to limitations with
 ``fast_filter_branch.py``, unannotated tags cannot be renamed
 (``fast_filter_branch.py`` considers them branches, not tags).  Since
 the upstream monorepo had its tags rewritten with an "llvmorg-"
 prefix, name conflicts should not be an issue.  ``--tag-prefix`` can
 be used to more clearly indicate which tags correspond to various
 imported repositories.
 
 Given this repository history::
 
-  R1 - R2 - R3 <- master
+  R1 - R2 - R3 <- main
        ^
        |
     release/1
 
 The above recipe results in a history like this::
 
-  U1 - U2 - U3 <- upstream/master
+  U1 - U2 - U3 <- upstream/main
    \    \    \
     \    -----\---------------                                         local/zip--.
      \         \              \                                                    |
     - Lllvm1 - Llld1 - UM3 -  Lclang1 - Lclang2 - Lllvm2 - Llld2 - Lmyproj1 - M1 <-'
                                                                              /
                                                                  R1 - R2 - R3  <-.
                                                                       ^           |
                                                                       |           |
                                                                myrepo-release/1   |
                                                                                   |
-                                                                   myrepo/master--'
+                                                                     myrepo/main--'
 
 Commits ``R1``, ``R2`` and ``R3`` have trees that *only* contain blobs
 from ``myrepo``.  If you require commits from ``myrepo`` to be
 interleaved with commits on local project branches (for example,
 interleaved with ``llvm1``, ``llvm2``, etc. above) and myrepo doesn't
 appear in an umbrella repository, a new tool will need to be
 developed.  Creating such a tool would involve:
 

 Scrubbing the Local Monorepo
 ----------------------------
 
 Once all of the migrating, zipping and importing is done, it's time to
 clean up.  The python tools use ``git-fast-import`` which leaves a lot
 of cruft around and we want to shrink our new monorepo mirror as much
 as possible.  Here is one way to do it::
 
-  git -C my-monorepo checkout master
+  git -C my-monorepo checkout main
 
   # Delete branches we no longer need.  Do this for any other branches
   # you merged above.
-  git -C my-monorepo branch -D local/zip/master || true
-  git -C my-monorepo branch -D local/octopus/master || true
+  git -C my-monorepo branch -D local/zip/main || true
+  git -C my-monorepo branch -D local/octopus/main || true
 
   # Remove remotes.
   git -C my-monorepo remote remove upstream/monorepo
 
   for p in ${my_projects[@]}; do
     git -C my-monorepo remote remove upstream/split/${p}
     git -C my-monorepo remote remove local/split/${p}
   done