aboutsummaryrefslogtreecommitdiff
path: root/doc/manual.cli
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manual.cli')
-rw-r--r--doc/manual.cli6
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/manual.cli b/doc/manual.cli
index bda4bc9..db157e6 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -24,7 +24,7 @@ The \c{bbot} architecture includes several layers for security and
manageability. At the top we have a \c{bbot} running in the \i{controller}
mode. The controller monitors various \i{build sources} for \i{build
tasks}. For example, a controller may poll a \c{brep} instances for any new
-packages to built as well as monitor a \c{git} repository for any new commits
+packages to built as well as monitor a \cb{git} repository for any new commits
to test. There can be several layers of controllers with \c{brep} being just a
special kind. A machine running a \c{bbot} instance in the controller mode is
called a \i{controller host}.
@@ -74,7 +74,7 @@ worker, to its agent, to its controller, and so on. A controller that is the
final destination of a build result uses email to notify interested parties of
the outcome. For example, \c{brep} would send a notification to the package
owner if the build failed. Similarly, a \c{bbot} controller that monitors a
-\c{git} repository would send an email to a committer if their commit caused a
+\cb{git} repository would send an email to a committer if their commit caused a
build failure. The email would include a link (normally HTTP/HTTPS) to the
build logs hosted by the controller.
@@ -348,7 +348,7 @@ The package version to build.
repository: <repository-url>
\
-The \c{bpkg} repository that contains the package and its dependencies.
+The \cb{pkg} repository that contains the package and its dependencies.
\h2#arch-task-trust|\c{trust}|