repo help
usage: repo COMMAND [ARGS]
The most commonly used repo commands are:
abandon Permanently abandon a development branch
branch View current topic branches
branches View current topic branches
checkout Checkout a branch for development
cherry-pick Cherry-pick a change.
diff Show changes between commit and working tree
diffmanifests Manifest diff utility
download Download and checkout a change
gitc-delete Delete a GITC Client.
gitc-init Initialize a GITC Client.
grep Print lines matching a pattern
info Get info on the manifest branch, current branch or unmerged branches
init Initialize a repo client checkout in the current directory
list List projects and their associated directories
overview Display overview of unmerged project branches
prune Prune (delete) already merged topics
rebase Rebase local branches on upstream branch
smartsync Update working tree to the latest known good revision
stage Stage file(s) for commit
start Start a new branch for development
status Show the working tree status
sync Update working tree to the latest revision
upload Upload changes for code review
See 'repo help <command>' for more information on a specific command.
See 'repo help --all' for a complete list of recognized commands.
Bug reports: https://bugs.chromium.org/p/gerrit/issues/entry?template=Repo+tool+issue
repo help init
Summary
Initialize a repo client checkout in the current directory
Usage: repo init [options] [manifest url]
Options:
-h, --help show this help message and exit
Logging options:
-v, --verbose show all output
-q, --quiet only show errors
Manifest options:
-u URL, --manifest-url=URL
manifest repository location
-b REVISION, --manifest-branch=REVISION
manifest branch or revision (use HEAD for default)
-m NAME.xml, --manifest-name=NAME.xml
initial manifest file
-g GROUP, --groups=GROUP
restrict manifest projects to ones with specified
group(s) [default|all|G1,G2,G3|G4,-G5,-G6]
-p PLATFORM, --platform=PLATFORM
restrict manifest projects to ones with a specified
platform group [auto|all|none|linux|darwin|...]
--submodules sync any submodules associated with the manifest repo
--standalone-manifest
download the manifest as a static file rather then
create a git checkout of the manifest repo
--manifest-depth=DEPTH
create a shallow clone of the manifest repo with given
depth (0 for full clone); see git clone (default: 0)
Manifest (only) checkout options:
-c, --current-branch
fetch only current manifest branch from server
(default)
--no-current-branch
fetch all manifest branches from server
--tags fetch tags in the manifest
--no-tags don't fetch tags in the manifest
Checkout modes:
--mirror create a replica of the remote repositories rather
than a client working directory
--archive checkout an archive instead of a git repository for
each project. See git archive.
--worktree use git-worktree to manage projects
Project checkout optimizations:
--reference=DIR location of mirror directory
--dissociate dissociate from reference mirrors after clone
--depth=DEPTH create a shallow clone with given depth; see git clone
--partial-clone perform partial clone (https://git-
scm.com/docs/gitrepository-
layout#_code_partialclone_code)
--no-partial-clone disable use of partial clone (https://git-
scm.com/docs/gitrepository-
layout#_code_partialclone_code)
--partial-clone-exclude=PARTIAL_CLONE_EXCLUDE
exclude the specified projects (a comma-delimited
project names) from partial clone (https://git-
scm.com/docs/gitrepository-
layout#_code_partialclone_code)
--clone-filter=CLONE_FILTER
filter for use with --partial-clone [default:
blob:none]
--use-superproject use the manifest superproject to sync projects;
implies -c
--no-use-superproject
disable use of manifest superprojects
--clone-bundle enable use of /clone.bundle on HTTP/HTTPS (default if
not --partial-clone)
--no-clone-bundle disable use of /clone.bundle on HTTP/HTTPS (default if
--partial-clone)
--git-lfs enable Git LFS support
--no-git-lfs disable Git LFS support
repo Version options:
--repo-url=URL repo repository location ($REPO_URL)
--repo-rev=REV repo branch or revision ($REPO_REV)
--no-repo-verify do not verify repo source code
Other options:
--config-name Always prompt for name/e-mail
Multi-manifest:
--outer-manifest operate starting at the outermost manifest
--no-outer-manifest
do not operate on outer manifests
--this-manifest-only
only operate on this (sub)manifest
--no-this-manifest-only, --all-manifests
operate on this manifest and its submanifests
Run `repo help init` to view the detailed manual.
Description
The 'repo init' command is run once to install and initialize repo. The latest
repo source code and manifest collection is downloaded from the server and is
installed in the .repo/ directory in the current working directory.
When creating a new checkout, the manifest URL is the only required setting. It
may be specified using the --manifest-url option, or as the first optional
argument.
The optional -b argument can be used to select the manifest branch to checkout
and use. If no branch is specified, the remote's default branch is used. This is
equivalent to using -b HEAD.
The optional -m argument can be used to specify an alternate manifest to be
used. If no manifest is specified, the manifest default.xml will be used.
If the --standalone-manifest argument is set, the manifest will be downloaded
directly from the specified --manifest-url as a static file (rather than setting
up a manifest git checkout). With --standalone-manifest, the manifest will be
fully static and will not be re-downloaded during subsesquent `repo init` and
`repo sync` calls.
The --reference option can be used to point to a directory that has the content
of a --mirror sync. This will make the working directory use as much data as
possible from the local reference directory when fetching from the server. This
will make the sync go a lot faster by reducing data traffic on the network.
The --dissociate option can be used to borrow the objects from the directory
specified with the --reference option only to reduce network transfer, and stop
borrowing from them after a first clone is made by making necessary local copies
of borrowed objects.
The --no-clone-bundle option disables any attempt to use $URL/clone.bundle to
bootstrap a new Git repository from a resumeable bundle file on a content
delivery network. This may be necessary if there are problems with the local
Python HTTP client or proxy configuration, but the Git binary works.
Switching Manifest Branches
To switch to another manifest branch, `repo init -b otherbranch` may be used in
an existing client. However, as this only updates the manifest, a subsequent
`repo sync` (or `repo sync -d`) is necessary to update the working directory
files.
repo help sync
Summary
Update working tree to the latest revision
Usage: repo sync [<project>...]
Options:
-h, --help show this help message and exit
-j JOBS, --jobs=JOBS number of jobs to run in parallel (default: 0; based
on number of CPU cores)
--jobs-network=JOBS number of network jobs to run in parallel (defaults to
--jobs or 1)
--jobs-checkout=JOBS number of local checkout jobs to run in parallel
(defaults to --jobs or 4)
-f, --force-broken obsolete option (to be deleted in the future)
--fail-fast stop syncing after first error is hit
--force-sync overwrite an existing git directory if it needs to
point to a different object directory. WARNING: this
may cause loss of data
--force-remove-dirty force remove projects with uncommitted modifications
if projects no longer exist in the manifest. WARNING:
this may cause loss of data
-l, --local-only only update working tree, don't fetch
--no-manifest-update, --nmu
use the existing manifest checkout as-is. (do not
update to the latest revision)
-n, --network-only fetch only, don't update working tree
-d, --detach detach projects back to manifest revision
-c, --current-branch fetch only current branch from server
--no-current-branch fetch all branches from server
-m NAME.xml, --manifest-name=NAME.xml
temporary manifest to use for this sync
--clone-bundle enable use of /clone.bundle on HTTP/HTTPS
--no-clone-bundle disable use of /clone.bundle on HTTP/HTTPS
-u MANIFEST_SERVER_USERNAME, --manifest-server-username=MANIFEST_SERVER_USERNAME
username to authenticate with the manifest server
-p MANIFEST_SERVER_PASSWORD, --manifest-server-password=MANIFEST_SERVER_PASSWORD
password to authenticate with the manifest server
--fetch-submodules fetch submodules from server
--use-superproject use the manifest superproject to sync projects;
implies -c
--no-use-superproject
disable use of manifest superprojects
--tags fetch tags
--no-tags don't fetch tags (default)
--optimized-fetch only fetch projects fixed to sha1 if revision does not
exist locally
--retry-fetches=RETRY_FETCHES
number of times to retry fetches on transient errors
--prune delete refs that no longer exist on the remote
(default)
--no-prune do not delete refs that no longer exist on the remote
--auto-gc run garbage collection on all synced projects
--no-auto-gc do not run garbage collection on any projects
(default)
-s, --smart-sync smart sync using manifest from the latest known good
build
-t SMART_TAG, --smart-tag=SMART_TAG
smart sync using manifest from a known tag
Logging options:
-v, --verbose show all output
-q, --quiet only show errors
Multi-manifest options:
--outer-manifest operate starting at the outermost manifest
--no-outer-manifest
do not operate on outer manifests
--this-manifest-only
only operate on this (sub)manifest
--no-this-manifest-only, --all-manifests
operate on this manifest and its submanifests
repo Version options:
--no-repo-verify do not verify repo source code
Run `repo help sync` to view the detailed manual.
Description
The 'repo sync' command synchronizes local project directories with the remote
repositories specified in the manifest. If a local project does not yet exist,
it will clone a new local directory from the remote repository and set up
tracking branches as specified in the manifest. If the local project already
exists, 'repo sync' will update the remote branches and rebase any new local
changes on top of the new remote changes.
'repo sync' will synchronize all projects listed at the command line. Projects
can be specified either by name, or by a relative or absolute path to the
project's local directory. If no projects are specified, 'repo sync' will
synchronize all projects listed in the manifest.
The -d/--detach option can be used to switch specified projects back to the
manifest revision. This option is especially helpful if the project is currently
on a topic branch, but the manifest revision is temporarily needed.
The -s/--smart-sync option can be used to sync to a known good build as
specified by the manifest-server element in the current manifest. The
-t/--smart-tag option is similar and allows you to specify a custom tag/label.
The -u/--manifest-server-username and -p/--manifest-server-password options can
be used to specify a username and password to authenticate with the manifest
server when using the -s or -t option.
If -u and -p are not specified when using the -s or -t option, 'repo sync' will
attempt to read authentication credentials for the manifest server from the
user's .netrc file.
'repo sync' will not use authentication credentials from -u/-p or .netrc if the
manifest server specified in the manifest file already includes credentials.
By default, all projects will be synced. The --fail-fast option can be used to
halt syncing as soon as possible when the first project fails to sync.
The --force-sync option can be used to overwrite existing git directories if
they have previously been linked to a different object directory. WARNING: This
may cause data to be lost since refs may be removed when overwriting.
The --force-remove-dirty option can be used to remove previously used projects
with uncommitted changes. WARNING: This may cause data to be lost since
uncommitted changes may be removed with projects that no longer exist in the
manifest.
The --no-clone-bundle option disables any attempt to use $URL/clone.bundle to
bootstrap a new Git repository from a resumeable bundle file on a content
delivery network. This may be necessary if there are problems with the local
Python HTTP client or proxy configuration, but the Git binary works.
The --fetch-submodules option enables fetching Git submodules of a project from
server.
The -c/--current-branch option can be used to only fetch objects that are on the
branch specified by a project's revision.
The --optimized-fetch option can be used to only fetch projects that are fixed
to a sha1 revision if the sha1 revision does not already exist locally.
The --prune option can be used to remove any refs that no longer exist on the
remote.
The --auto-gc option can be used to trigger garbage collection on all projects.
By default, repo does not run garbage collection.
SSH Connections
If at least one project remote URL uses an SSH connection (ssh://, git+ssh://,
or user@host:path syntax) repo will automatically enable the SSH ControlMaster
option when connecting to that host. This feature permits other projects in the
same 'repo sync' session to reuse the same SSH tunnel, saving connection setup
overheads.
To disable this behavior on UNIX platforms, set the GIT_SSH environment variable
to 'ssh'. For example:
export GIT_SSH=ssh
repo sync
Compatibility
This feature is automatically disabled on Windows, due to the lack of UNIX
domain socket support.
This feature is not compatible with url.insteadof rewrites in the user's
~/.gitconfig. 'repo sync' is currently not able to perform the rewrite early
enough to establish the ControlMaster tunnel.
If the remote SSH daemon is Gerrit Code Review, version 2.0.10 or later is
required to fix a server side protocol bug.