Repo Primer for Zephyr microPlatform

This section describes Repo and how the Zephyr microPlatform uses it. If you’re unfamiliar with Repo, it may make things clearer.

Manifest Repository

A Zephyr microPlatform installation contains multiple Git repositories, which are managed by a manifest file in a Repo manifest repository.

The manifest repository’s name is zmp-manifest. It’s a Git repository, just like any of the source code repositories. When installing the Zephyr microPlatform, repo init is given the URL for the manifest repository.

The manifest repository contains a manifest file, named default.xml. This file describes the other Git repositories in the Zephyr microPlatform installation, and their metadata.

Roughly speaking, the manifest file contains:

  • remotes, which specify where Zephyr microPlatform repositories are hosted.
  • projects, which specify the Git repositories that make up the microPlatform, along with the remotes to fetch them from, and Git branches to check out.

The following figure ties together the various pieces.

Example Repo manifest

Basic Repo Usage

When you installed the Zephyr microPlatform, you ran something like this:

mkdir zmp && cd zmp
repo init -u https://some-url/zmp-manifest [-b some-tag]
repo sync

This checks out the manifest file in the manifest repository and puts it in a hidden .repo subdirectory of zmp. If you specify a tag, that revision of the manifest is used; otherwise, master is used.

During installation, repo sync is run after repo init. This parses the manifest file in the .repo directory, clones the repositories it names as projects, then checks them out locally in zmp.

Running repo sync again later on fetches changes to the manifest, then re-synchronizes the local trees. This also attempts to rebase any locally checked out branches.


If you’ve got locally checked out branches when you run repo sync, your Git history is rewritten. This happens because the local branch is rebased onto the new commit from

If you’re concerned about the effects of the rebase, use repo sync -n to fetch changes from the network, but leave local working trees unchanged. You can then inspect the upstream branches and integrate them manually.