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

1 files changed, 4 insertions, 4 deletions

diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index 739ea38795..358b53a8db 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/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.