*: rename master to main in tests & examples

3 files changed, 13 insertions, 13 deletions

diff --git a/docs/atomic-upgrades.md b/docs/atomic-upgrades.md
index 6d58d845..92ae2c49 100644
--- a/docs/atomic-upgrades.md
+++ b/docs/atomic-upgrades.md
@@ -25,8 +25,8 @@ implements this.
 
 To begin a simple upgrade, OSTree fetches the contents of the ref from
 the remote server.  Suppose we're tracking a ref named
-`exampleos/buildmaster/x86_64-runtime`.  OSTree fetches the URL
-`http://example.com/repo/refs/heads/exampleos/buildmaster/x86_64-runtime`,
+`exampleos/buildmain/x86_64-runtime`.  OSTree fetches the URL
+`http://example.com/repo/refs/heads/exampleos/buildmain/x86_64-runtime`,
 which contains a SHA256 checksum.  This determines the tree to deploy,
 and `/etc` will be merged from currently booted tree.
 
diff --git a/docs/repo.md b/docs/repo.md
index 0269934e..69f26172 100644
--- a/docs/repo.md
+++ b/docs/repo.md
@@ -123,16 +123,16 @@ commits.  See the
 for information on how git uses them.  Unlike git though, it doesn't
 usually make sense to have a "main" branch.  There is a convention
 for references in OSTree that looks like this:
-`exampleos/buildmaster/x86_64-runtime` and
-`exampleos/buildmaster/x86_64-devel-debug`.  These two refs point to
+`exampleos/buildmain/x86_64-runtime` and
+`exampleos/buildmain/x86_64-devel-debug`.  These two refs point to
 two different generated filesystem trees.  In this example, the
 "runtime" tree contains just enough to run a basic system, and
 "devel-debug" contains all of the developer tools and debuginfo.
 
 The `ostree` supports a simple syntax using the caret `^` to refer to
 the parent of a given commit.  For example,
-`exampleos/buildmaster/x86_64-runtime^` refers to the previous build,
-and `exampleos/buildmaster/x86_64-runtime^^` refers to the one before
+`exampleos/buildmain/x86_64-runtime^` refers to the previous build,
+and `exampleos/buildmain/x86_64-runtime^^` refers to the one before
 that.
 
 ## The summary file
diff --git a/docs/repository-management.md b/docs/repository-management.md
index 7dda781d..2db6383a 100644
--- a/docs/repository-management.md
+++ b/docs/repository-management.md
@@ -80,7 +80,7 @@ Then, what you'll want to do is promote content from "dev" to "prod".
 We'll discuss this later, but first, let's talk about promotion
 *inside* our "dev" repository.
 
-## Promoting content along OSTree branches - "buildmaster", "smoketested"
+## Promoting content along OSTree branches - "buildmain", "smoketested"
 
 Besides multiple repositories, OSTree also supports multiple branches
 inside one repository, equivalent to git's branches.  We saw in an
@@ -88,16 +88,16 @@ earlier section an example branch name like
 `exampleos/x86_64/standard`.  Choosing the branch name for your "prod"
 repository is absolutely critical as client systems will reference it.
 It becomes an important part of your face to the world, in the same
-way the "master" branch in a git repository is.
+way the "main" branch in a git repository is.
 
 But with your "dev" repository internally, it can be very useful to
 use OSTree's branching concepts to represent different stages in a
 software delivery pipeline.
 
 Deriving from `exampleos/x86_64/standard`, let's say our "dev"
-repository contains `exampleos/x86_64/buildmaster/standard`.  We choose the
-term "buildmaster" to represent something that came straight from git
-master.  It may not be tested very much.
+repository contains `exampleos/x86_64/buildmain/standard`.  We choose the
+term "buildmain" to represent something that came straight from git
+main.  It may not be tested very much.
 
 Our next step should be to hook up a testing system (Jenkins,
 Buildbot, etc.) to this.  When a build (commit) passes some tests, we
@@ -106,14 +106,14 @@ want to "promote" that commit.  Let's create a new branch called
 complete system.  This might be where human testers get involved, for
 example.
 
-This is a basic way to "promote" the `buildmaster` commit that passed testing:
+This is a basic way to "promote" the `buildmain` commit that passed testing:
 
 ```
 ostree commit -b exampleos/x86_64/smoketested/standard -s 'Passed tests' --tree=ref=aec070645fe53...
 ```
 
 Here we're generating a new commit object (perhaps include in the commit
-log links to build logs, etc.), but we're reusing the *content* from the `buildmaster`
+log links to build logs, etc.), but we're reusing the *content* from the `buildmain`
 commit `aec070645fe53` that passed the smoketests.
 
 For a more sophisticated implementation of this model, see the