Rewrite documentation on primary branch usage for Tor.git.

This patch is part of a series of patches where we try to change our
primary branch name of tor.git from master to main.

See: tpo/core/team#2

doc/HACKING/CodingStandards.md

@@ -59,7 +59,7 @@ Some compatible licenses include:
 Each main development series (like 0.2.1, 0.2.2, etc) has its main work
 applied to a single branch.  At most one series can be the development series
 at a time; all other series are maintenance series that get bug-fixes only.
-The development series is built in a git branch called "master"; the
+The development series is built in a git branch called "main"; the
 maintenance series are built in branches called "maint-0.2.0", "maint-0.2.1",
 and so on.  We regularly merge the active maint branches forward.
 
@@ -75,7 +75,7 @@ If you're working on a bugfix for a bug that occurs in a particular version,
 base your bugfix branch on the "maint" branch for the first supported series
 that has that bug.  (As of June 2013, we're supporting 0.2.3 and later.)
 
-If you're working on a new feature, base it on the master branch. If you're
+If you're working on a new feature, base it on the main branch. If you're
 working on a new feature and it will take a while to implement and/or you'd
 like to avoid the possibility of unrelated bugs in Tor while you're
 implementing your feature, consider branching off of the latest maint- branch.

doc/HACKING/GettingStarted.md

@@ -41,7 +41,7 @@ Once you've reached this point, here's what you need to know.
      $ git clone https://git.torproject.org/git/tor
      ```
 
-     This will give you a checkout of the master branch.  If you're
+     This will give you a checkout of the main branch.  If you're
      going to fix a bug that appears in a stable version, check out the
      appropriate "maint" branch, as in:
 

doc/HACKING/HelpfulTools.md

@@ -33,8 +33,8 @@ OFTC. If they don't, ask #tor-dev (also on OFTC).
 It's CI/builders. Looks like this: https://jenkins.torproject.org
 
 Runs automatically on commits merged to git.torproject.org. We CI the
-master branch and all supported tor versions. We also build nightly debian
+main branch and all supported tor versions. We also build nightly debian
-packages from master.
+packages from main.
 
 Builds Linux and Windows cross-compilation. Runs Linux tests.
 

doc/HACKING/Maintaining.md

@@ -7,7 +7,7 @@ The first section describes who is the current Tor maintainer and what are the
 responsibilities. Tor has one main single maintainer but does have many
 committers and subsystem maintainers.
 
-The second third section describes how the **alpha and master** branches are
+The second third section describes how the **alpha and main** branches are
 maintained and by whom.
 
 Finally, the last section describes how the **stable** branches are maintained
@@ -25,7 +25,7 @@ protocol design. Releasing Tor falls under their responsibility.
 
 ## Alpha and Master Branches
 
-The Tor repository always has at all times a **master** branch which contains
+The Tor repository always has at all times a **main** branch which contains
 the upstream ongoing development.
 
 It may also contain a branch for a released feature freezed version which is
@@ -37,7 +37,7 @@ Tor is separated into subsystems and some of those are maintained by other
 developers than the main maintainer. Those people have commit access to the
 code base but only commit (in most cases) into the subsystem they maintain.
 
-Upstream merges are restricted to the alpha and master branches. Subsystem
+Upstream merges are restricted to the alpha and main branches. Subsystem
 maintainers should never push a patch into a stable branch which is the
 responsibility of the [stable branch maintainer](#stable-branches).
 
@@ -69,7 +69,7 @@ maintain the following subsystems:
 These are the tasks of a subsystem maintainer:
 
 1. Regularly go over `merge_ready` tickets relevant to the related subsystem
-   and for the current alpha or development (master branch) Milestone.
+   and for the current alpha or development (main branch) Milestone.
 
 2. A subsystem maintainer is expected to contribute to any design changes
    (including proposals) or large patch set about the subsystem.
@@ -102,7 +102,7 @@ These are few important items to follow when merging code upstream:
 
 4. Tor uses the "merge forward" method, that is, if a patch applies to the
    alpha branch, it has to be merged there first and then merged forward
-   into master.
+   into main.
 
 5. Maintainer should always consult with the network team about any doubts,
    mis-understandings or unknowns of a patch. Final word will always go to the

doc/HACKING/ReleaseSeriesLifecycle.md

@@ -87,17 +87,17 @@ they do not apply to security-related patch release versions.
 
 (Ideally, do this immediately after a release.)
 
-1. Start a new maint-x.y.z branch based on master, and a new
+1. Start a new maint-x.y.z branch based on main, and a new
-   release-x.y.z branch based on master. They should have the same
+   release-x.y.z branch based on main. They should have the same
    starting point.
 
-   Push both of these branches to the master git repository.
+   Push both of these branches to the canonical git repository.
 
-2. In master, change the version to "0.x.y.0-alpha-dev". Run the
+2. In the main branch, change the version to "0.x.y.0-alpha-dev". Run the
    update_versions.py script, and commit this version bump.
 
 3. Tag the version bump with "tor-0.x.y.0-alpha-dev". Push the tag
-   and master.
+   and main branch.
 
 4. Open tickets for connecting the new branches to various other
    places.  See section 2 above for a list of affected locations.
@@ -107,7 +107,7 @@ they do not apply to security-related patch release versions.
      target in the maint-x.y.z branch only.
    * Delete the file scripts/maint/practracker/.enable_practracker_in_hooks
      in the maint-x.y.z branch only.
-   * Merge to release-x.y.z, but do not forward-port to master.
+   * Merge to release-x.y.z, but do not forward-port to the main branch.
 
 6. Finally, make sure this document is up to date with our latest
    process.

doc/HACKING/ReleasingTor.md

@@ -110,7 +110,7 @@ new Tor release:
    note added to each section.  So in this case, once you have the items
    from the changes files copied together, don't use them to build a new
    changelog: instead, look up the corrected versions that were merged
-   into ChangeLog in the master branch, and use those.
+   into ChangeLog in the main branch, and use those.
 
    Add "backport from X.Y.Z" in the section header for these entries.
 
@@ -142,7 +142,7 @@ new Tor release:
    places, and commit.  Then merge `maint-0.?.x` into `release-0.?.x`.
 
    When you merge the maint branch forward to the next maint branch, or into
-   master, merge it with "-s ours" to avoid conflict with the version
+   main, merge it with "-s ours" to avoid conflict with the version
    bump.
 
 2. Make distcheck, put the tarball up in somewhere (how about your
@@ -222,13 +222,13 @@ $ git push origin tag tor-0.4.x.y-<status>
 
 1. If it's a stable release, bump the version number in the
    `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`
-   merge to avoid taking that change into master.
+   merge to avoid taking that change into main.
 
 2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that
    builds the release every week. (It's ok to skip the weekly build if the
    branch was updated in the last 24 hours.)
 
 3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
-   master branch.
+   main branch.
 
 4. Keep an eye on the blog post, to moderate comments and answer questions.

scripts/maint/findMergedChanges.pl

@@ -22,13 +22,13 @@ Usage:
    findMergedChanges.pl [--merged/--unmerged/--weird/--list] [--branch=<branchname] [--head=<branchname>] changes/*
 
 A change is "merged" if it has ever been merged to release-0.2.4 and it has had
-no subsequent changes in master.
+no subsequent changes in main.
 
 A change is "unmerged" if it has never been merged to release-0.2.4 and it
-has had changes in master.
+has had changes in main.
 
 A change is "weird" if it has been merged to release-0.2.4 and it *has* had
-subsequent changes in master.
+subsequent changes in main.
 
 Suggested application:
    findMergedChanges.pl --merged changes/* | xargs -n 1 git rm
@@ -37,7 +37,7 @@ EOF
 }
 
 my $target_branch = "origin/release-0.2.4";
-my $head = "origin/master";
+my $head = "origin/main";
 
 while (@ARGV and $ARGV[0] =~ /^--/) {
     my $flag = shift @ARGV;