REPO(1)

📦
version 2.69 · 10 versions
, in fedora 43, fedora 44

🎀 REPO(1) — the Repo Manual 🎀

okay so bestie 💖 welcome to the Repo Manual, aka the manual page for repo manifest. This is part one of three, so grab a snack and stay with me 👑

✨ NAME ✨

repo — repo manifest — manual page for repo manifest 💅

📜 SYNOPSIS 📜

repo manifest [-o {-|NAME.xml}] [-m MANIFEST.xml] [-r]

that's the whole summoning circle right there, no cap ✨

💫 DESCRIPTION 💫

🌟 Summary 🌟

Manifest inspection utility 🔍 — she looks at manifests and tells you what's up, periodt.

🌸 OPTIONS 🌸

  • -h, --help — show this help message and exit. the classic escape hatch, iconic, we love her 🫶
  • -r, --revision-as-HEAD — save revisions as current HEAD
  • *-m *NAME.xml, --manifest-name=NAME.xml — temporary manifest to use for this sync
  • --suppress-upstream-revision — if you're in -r mode, don't write the upstream field (only of use if the branch names for a sha1 manifest are sensitive) 🙈
  • --suppress-dest-branch — if you're in -r mode, don't write the dest-branch field (only of use if the branch names for a sha1 manifest are sensitive)
  • *--format=FORMAT* — output format: xml, json (default: xml)
  • --pretty — format output for humans to read 💖
  • --no-local-manifests — ignore local manifests
  • *-o *-|NAME.xml, --output-file=-|NAME.xml — file to save the manifest to. (Filename prefix for multi-tree.)

🌙 Logging options: 🌙

  • -v, --verbose — show all output. all of it. every crumb 🍓
  • -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

Run repo help manifest to view the detailed manual. 📚

🔍 DETAILS 🔍

okay here's the tea ☕ With the -o option, repo exports the current manifest so you can inspect it. The manifest and (if it's there) local_manifests/ get combined together to produce a single manifest file. You can keep that file in a Git repository and use it during future repo init invocations. slay 💅

The -r option can be used to generate a manifest file with project revisions set to the current commit hash. These are known as "revision locked manifests", because they don't follow any particular branch — they're committed to the bit, fr fr. In this case, the 'upstream' attribute is set to the ref we were on when the manifest was generated. The 'dest-branch' attribute is set to indicate the remote ref to push changes to via repo upload.

Multiple output formats are supported via --format. The default output is XML, and formats are generally "condensed". Use --pretty for more human-readable variations ✨

📖 repo Manifest Format 📖

A repo manifest describes the structure of a repo client; that is the directories that are visible and where they should be obtained from with git.

The basic structure of a manifest is a bare Git repository holding a single default.xml XML file in the top level directory.

Manifests are inherently version controlled, since they are kept within a Git repository. Updates to manifests are automatically obtained by clients during repo sync. 🦋

[TOC]

🌈 XML File Format 🌈

A manifest XML file (e.g. default.xml) roughly conforms to the following DTD:


<!ELEMENT manifest (notice?,
       remote*, default?, manifest-server?, submanifest*?,
       remove-project*, project*, extend-project*, repo-hooks?,
       superproject?, contactinfo?, include*)>

       <!ELEMENT notice (#PCDATA)>

       <!ELEMENT remote (annotation*)> <!ATTLIST remote name         ID
       #REQUIRED> <!ATTLIST remote alias        CDATA #IMPLIED>
       <!ATTLIST remote fetch        CDATA #REQUIRED> <!ATTLIST remote
       pushurl      CDATA #IMPLIED> <!ATTLIST remote review       CDATA
       #IMPLIED> <!ATTLIST remote revision     CDATA #IMPLIED>

       <!ELEMENT default EMPTY> <!ATTLIST default remote         IDREF
       #IMPLIED> <!ATTLIST default revision       CDATA #IMPLIED>
       <!ATTLIST default dest-branch    CDATA #IMPLIED> <!ATTLIST
       default upstream       CDATA #IMPLIED> <!ATTLIST default sync-j
       CDATA #IMPLIED> <!ATTLIST default sync-j-max     CDATA #IMPLIED>
       <!ATTLIST default sync-c         CDATA #IMPLIED> <!ATTLIST
       default sync-s         CDATA #IMPLIED> <!ATTLIST default
       sync-tags      CDATA #IMPLIED> <!ATTLIST default sync-smartsync
       CDATA #IMPLIED>

       <!ELEMENT manifest-server EMPTY> <!ATTLIST manifest-server url
       CDATA #REQUIRED> <!ATTLIST manifest-server helper CDATA #IMPLIED>

       <!ELEMENT submanifest EMPTY> <!ATTLIST submanifest name
       ID    #REQUIRED> <!ATTLIST submanifest remote         IDREF
       #IMPLIED> <!ATTLIST submanifest project        CDATA #IMPLIED>
       <!ATTLIST submanifest manifest-name  CDATA #IMPLIED> <!ATTLIST
       submanifest revision       CDATA #IMPLIED> <!ATTLIST submanifest
       path           CDATA #IMPLIED> <!ATTLIST submanifest groups
       CDATA #IMPLIED> <!ATTLIST submanifest default-groups CDATA
       #IMPLIED>

<!ELEMENT project (annotation*,
       project*, copyfile*, linkfile*)>

<!ATTLIST project name
       CDATA #REQUIRED>

<!ATTLIST project path
       CDATA #IMPLIED>

<!ATTLIST project remote
       IDREF #IMPLIED>

<!ATTLIST project revision
       CDATA #IMPLIED>

<!ATTLIST project dest-branch
       CDATA #IMPLIED>

<!ATTLIST project groups
       CDATA #IMPLIED>

<!ATTLIST project sync-c
       CDATA #IMPLIED>

<!ATTLIST project sync-s
       CDATA #IMPLIED>

<!ATTLIST project sync-tags
       CDATA #IMPLIED>

<!ATTLIST project upstream
       CDATA #IMPLIED>

<!ATTLIST project clone-depth
       CDATA #IMPLIED>

<!ATTLIST project force-path
       CDATA #IMPLIED>

       <!ATTLIST project sync-strategy CDATA #IMPLIED>

       <!ELEMENT annotation EMPTY> <!ATTLIST annotation name  CDATA
       #REQUIRED> <!ATTLIST annotation value CDATA #REQUIRED> <!ATTLIST
       annotation keep  CDATA "true">

       <!ELEMENT copyfile EMPTY> <!ATTLIST copyfile src  CDATA
       #REQUIRED> <!ATTLIST copyfile dest CDATA #REQUIRED>

       <!ELEMENT linkfile EMPTY> <!ATTLIST linkfile src  CDATA
       #REQUIRED> <!ATTLIST linkfile dest CDATA #REQUIRED>

<!ELEMENT extend-project (annotation*,
       copyfile*, linkfile*)>

<!ATTLIST extend-project name
       CDATA #REQUIRED>

<!ATTLIST extend-project path
       CDATA #IMPLIED>

<!ATTLIST extend-project dest-path
       CDATA #IMPLIED>

<!ATTLIST extend-project groups
       CDATA #IMPLIED>

<!ATTLIST extend-project revision
       CDATA #IMPLIED>

<!ATTLIST extend-project remote
       CDATA #IMPLIED>

       <!ATTLIST extend-project dest-branch CDATA #IMPLIED> <!ATTLIST
       extend-project upstream    CDATA #IMPLIED> <!ATTLIST
       extend-project base-rev    CDATA #IMPLIED>

       <!ELEMENT remove-project EMPTY> <!ATTLIST remove-project name
       CDATA #IMPLIED> <!ATTLIST remove-project path     CDATA #IMPLIED>
       <!ATTLIST remove-project optional CDATA #IMPLIED> <!ATTLIST
       remove-project base-rev CDATA #IMPLIED>

       <!ELEMENT repo-hooks EMPTY> <!ATTLIST repo-hooks in-project
       CDATA #REQUIRED> <!ATTLIST repo-hooks enabled-list CDATA
       #REQUIRED>

       <!ELEMENT superproject EMPTY> <!ATTLIST superproject name
       CDATA #REQUIRED> <!ATTLIST superproject remote   IDREF #IMPLIED>
       <!ATTLIST superproject revision CDATA #IMPLIED>

       <!ELEMENT contactinfo EMPTY> <!ATTLIST contactinfo bugurl CDATA
       #REQUIRED>

       <!ELEMENT include EMPTY> <!ATTLIST include name     CDATA
       #REQUIRED> <!ATTLIST include groups   CDATA #IMPLIED> <!ATTLIST
       include revision CDATA #IMPLIED>

]> ```

For compatibility purposes across repo releases, all unknown elements are silently ignored. However, repo reserves all possible names for itself for future use. If you want to use custom elements, the x-* namespace is reserved for that purpose, and repo guarantees to never allocate any corresponding names. 🛡️

A description of the elements and their attributes follows.

🌟 Element manifest 🌟

The root element of the file. the main character, honestly 👑

💌 Element notice 💌

Arbitrary text that is displayed to users whenever repo sync finishes. The content is simply passed through as it exists in the manifest.

🛰️ Element remote 🛰️

One or more remote elements may be specified. Each remote element specifies a Git URL shared by one or more projects and (optionally) the Gerrit review server those projects upload changes through.

  • Attribute name: A short name unique to this manifest file. The name specified here is used as the remote name in each project's .git/config, and is therefore automatically available to commands like git fetch, git remote, git pull and git push.
  • Attribute alias: The alias, if specified, is used to override name to be set as the remote name in each project's .git/config. Its value can be duplicated while attribute name has to be unique in the manifest file. This helps each project to be able to have same remote name which actually points to different remote url.
  • Attribute fetch: The Git URL prefix for all projects which use this remote. Each project's name is appended to this prefix to form the actual URL used to clone the project.
  • Attribute pushurl: The Git "push" URL prefix for all projects which use this remote. Each project's name is appended to this prefix to form the actual URL used to "git push" the project. This attribute is optional; if not specified then "git push" will use the same URL as the fetch attribute.
  • Attribute review: Hostname of the Gerrit server where reviews are uploaded to by repo upload. This attribute is optional; if not specified then repo upload will not function.
  • Attribute revision: Name of a Git branch (e.g. main or refs/heads/main). Remotes with their own revision will override the default revision.

🎀 Element default 🎀

At most one default element may be specified. Its remote and revision attributes are used when a project element does not specify its own remote or revision attribute.

  • Attribute remote: Name of a previously defined remote element. Project elements lacking a remote attribute of their own will use this remote.
  • Attribute revision: Name of a Git branch (e.g. main or refs/heads/main). Project elements lacking their own revision attribute will use this revision.
  • Attribute dest-branch: Name of a Git branch (e.g. main). Project elements not setting their own dest-branch will inherit this value. If this value is not set, projects will use revision by default instead.
  • upstream — the name of the Git ref where a sha1 can be found 👀. It gets used when you're syncing a revision-locked manifest in -c mode, so you don't have to drag the entire ref space across the wire (ur bandwidth said thank u). Any project element that doesn't set its own upstream inherits this value. 💖
  • sync-j — how many parallel jobs to use when syncing. Go wild (responsibly).
  • sync-j-max — the maximum number of parallel jobs to use when syncing. That's the ceiling, bestie.
  • sync-c — set to true to only sync the given Git branch (the one in the revision attribute) instead of the whole ref space. Project elements that don't have a sync-c of their own will use this value.
  • sync-s — set to true to also sync sub-projects. yes queen, all of them.
  • sync-tags — set to false to only sync the given Git branch (specified in the revision attribute) rather than the other ref tags. (Yep, it's a false-to-do-less situation, read it twice.)
  • sync-smartsync — set to true to enable smart sync by default. ✨

🫶 Element manifest-server

You can specify at most one manifest-server — one and done, no extras 🙅. The url attribute is what you use to specify the URL of a manifest server, which is an XML RPC service. For the full lore, go look at the smart sync documentation over at ./smart-sync.md. 🧚

  • url — the URL of the manifest server. That's the whole vibe.
  • helper — optional name of a remote helper binary to execute, used to resolve proxying or authentication for the manifest server. Lowkey useful when your network is doing the most. 🔥

🦋 Element submanifest

One or more submanifest elements may be specified. Each element describes a single manifest to be checked out as a child. It's giving… manifests within manifests. 🎀

  • name — a unique name (within the current (sub)manifest) for this submanifest. It acts as a default for revision down below. Fun fact: the same name can be used for submanifests with different parent (sub)manifests. 💅
  • remote — the name of a previously defined remote element. If you don't supply it, the remote given by the default element is used.
  • project — the manifest project name. The project's name gets appended onto its remote's fetch URL to generate the actual URL to configure the Git remote with. The URL gets formed as:
${remote_fetch}/${project_name}.git

where ${remote_fetch} is the remote's fetch attribute and ${project_name} is the project's name attribute. The suffix .git is always appended, because repo assumes the upstream is a forest of bare Git repositories. If the project has a parent element, its name will be prefixed by the parent's. 🌳

The project name must match the name Gerrit knows, if Gerrit is being used for code reviews. 👑

project must not be empty, and may not be an absolute path or use . or .. path components. It is always interpreted relative to the remote's fetch settings, so if a different base path is needed, declare a different remote with the new settings needed.

If not supplied, the remote and project for this manifest will be used: remote cannot be supplied. (Yeah. Those are mutually exclusive, don't fight it.)

Projects from a submanifest and its submanifests are added to the submanifest::path:<path_prefix> group. 🫶

  • manifest-name — the manifest filename in the manifest project. If not supplied, default.xml is used.
  • revision — name of a Git branch (e.g. "main" or "refs/heads/main"), tag (e.g. "refs/tags/stable"), or a commit hash. If not supplied, name is used.
  • path — an optional path relative to the top directory of the repo client, i.e. where the submanifest repo client top directory should be placed. If not supplied, revision is used.
path may not be an absolute path or use . or .. path components. 🚫
  • groups — the set of additional groups to which all projects in the included submanifest belong. This appends and recurses, meaning all projects in submanifests carry all parent submanifest groups. Same syntax as the corresponding element of project. 🪆
  • default-groups — the list of manifest groups to sync if no --groups= parameter was specified at init. When that list is empty, use this list instead of "default" as the list of groups to sync. periodt.

👑 Element project

One or more project elements may be specified. Each element describes a single Git repository to be cloned into the repo client workspace. You may specify Git-submodules by creating a nested project. Git-submodules will be automatically recognized and inherit their parent's attributes — but those may be overridden by an explicitly specified project element. So yeah, you can fight your inheritance and win. 💪

  • name — a unique name for this project. The project's name is appended onto its remote's fetch URL to generate the actual URL to configure the Git remote with. The URL gets formed as:
${remote_fetch}/${project_name}.git

where ${remote_fetch} is the remote's fetch attribute and ${project_name} is the project's name attribute. The suffix .git is always appended, because repo assumes the upstream is a forest of bare Git repositories. If the project has a parent element, its name will be prefixed by the parent's.

The project name must match the name Gerrit knows, if Gerrit is being used for code reviews. 👑

"name" must not be empty, and may not be an absolute path or use . or .. path components. It is always interpreted relative to the remote's fetch settings, so if a different base path is needed, declare a different remote with the new settings needed. These restrictions are not enforced for Local Manifests. 🙈

  • path — an optional path relative to the top directory of the repo client, where the Git working directory for this project should be placed. If not supplied, the project "name" is used. If the project has a parent element, its path will be prefixed by the parent's.
"path" may not be an absolute path or use . or .. path components. These restrictions are not enforced for Local Manifests.

If you want to place files into the root of the checkout (like a README or Makefile or another build script), use the copyfile or linkfile elements instead. That's the move, bestie. 🌸

  • remote — the name of a previously defined remote element. If not supplied, the remote given by the default element is used.
  • revision — the name of the Git branch the manifest wants to track for this project. Names can be relative to refs/heads (e.g. just "main") or absolute (e.g. "refs/heads/main"). Tags and/or explicit SHA-1s should work in theory, but have not been extensively tested. (it's giving "we've never tried it, good luck babe" 💀) If not supplied, the revision given by the remote element is used if applicable, else the default element is used.
  • dest-branch — name of a Git branch (e.g. main). When you use repo upload, changes will be submitted for code review on this branch. If unspecified both here and in the default element, revision is used instead.
  • groups — the set of groups to which this project belongs, whitespace or comma separated. All projects belong to the group "all", and each project automatically belongs to a group of its name:name and path:path. E.g. for <project name="monkeys" path="barrel-of"/>, that project definition is implicitly in the following manifest groups: default, name:monkeys, and path:barrel-of. If you place a project in the group "notdefault", it will not be automatically downloaded by repo. If the project has a parent element, the name and path here are the prefixed ones. 🐒
  • sync-c — set to true to only sync the given Git branch (specified in the revision attribute) rather than the whole ref space.
  • sync-s — set to true to also sync sub-projects.
  • upstream — name of the Git ref in which a sha1 can be found. Used when syncing a revision-locked manifest in -c mode to avoid having to sync the entire ref space.
  • clone-depth — set the depth to use when fetching this project. If specified, this value will override any value given to repo init with the --depth option on the command line. Your flag got outranked, sorry not sorry. 💅
  • force-path — set to true to force this project to create the local mirror repository according to its path attribute (if supplied) rather than the name attribute. This attribute only applies to the local mirrors syncing — it will be ignored when syncing the projects in a client working directory. Important distinction, don't mix it up. 👀
  • sync-strategy — set the sync strategy used when fetching this project. Currently the only supported value is stateless. When set to stateless, repo will run a reflog expiration and aggressive garbage collection at the end of the sync process. This is useful for projects that contain large binary files and use clone-depth="1", where garbage can accumulate as binaries are added, deleted, or modified across successive syncs. 🔥

During a stateless sync, repo checks the following before cleaning up:

  1. The project does not share an object directory with other projects.
  2. The working tree is clean (no uncommitted changes, no untracked files).
  3. There are no unpushed local commits.
  4. There is no Git stash.

If any of these conditions are not met, repo falls back to a standard sync without garbage collection. No clean-up, no drama, just business as usual. 🧹

💜 Element extend-project

Modify the attributes of the named project. This element is mostly useful in a local manifest file, to modify the attributes of an existing project without completely replacing the existing project definition. That makes the local manifest way more robust against changes to the original manifest — resilient queen. 👑

The extend-project element can also contain annotation, copyfile, and linkfile child elements. These are added to the project's definition. A copyfile or linkfile with a dest that already exists in the project will overwrite the original. Yes, overwrite. It said what it said. 😭

  • path — if specified, limit the change to projects checked out at the specified path, rather than all projects with the given name.
  • dest-path — if specified, a path relative to the top directory of the repo client where the Git working directory for this project should be placed. This is used to move a project in the checkout by overriding the existing path setting.
  • groups — set of additional groups to which this project belongs. Same syntax as the corresponding element of project.
  • revision — if specified, overrides the revision of the original project. Same syntax as the corresponding element of project.
  • remote — if specified, overrides the remote of the original project. Same syntax as the corresponding element of project.
  • dest-branch — if specified, overrides the dest-branch of the original project. Same syntax as the corresponding element of project.
  • upstream — if specified, overrides the upstream of the original project. Same syntax as the corresponding element of project.
  • base-rev — set this and repo adds a whole extra check against the revision that's being extended 🕵️💅. If the revisions you're extending have changed since base-rev was set, the manifest parse will fail and give you a list of mismatch extends. It's made for layered manifests that use hash revisions, and its whole job is stopping patch branches from hiding newer upstream revisions 💀. It also compares named refs like branches or tags — but ngl it gets misleading if branches are used as base-rev. Same syntax as the corresponding element of project.

🌸 Element annotation 🌸

You can put zero or more annotation elements as children of a project element, an extend-project element, or a remote element. Each one is describing a name-value pair, periodt. For projects, that name-value pair gets exported into each project's environment during a forall command, prefixed with REPO__ ✨.

Also there's an optional keep attribute that accepts the case insensitive values true (default) or false. It determines whether or not the annotation will be kept when exported with the manifest subcommand. That's the whole vibe check.

🎀 Element copyfile 🎀

Zero or more copyfile elements may be specified as children of a project element, or an extend-project element. Each element describes a src-dest pair of files; the src file will be copied to the dest place during the repo sync command 💖.

src is project relative, dest is relative to the top of the tree. Copying from paths outside of the project or to paths outside of the repo client is not allowed 🚫.

src and dest must be files. Directories or symlinks are not allowed, and intermediate paths must not be symlinks either. Not even a little. Iconic of it to be strict? Yes.

Parent directories of dest will be automatically created if missing 🫶.

The files are copied in the order they are specified in the manifests. If multiple elements specify the same source and destination, they will only be applied as one, based on the first occurence. Files are copied before any links specified via linkfile elements are created. Ordering matters, bestie, don't fight it.

🦋 Element linkfile 🦋

It's just like copyfile, but instead of copying it creates a symlink ✨.

The symlink is created at dest (relative to the top of the tree) and points to the path specified by src, which is a path in the project.

Parent directories of dest will be automatically created if missing.

The symlink target may be a file or directory, but it may not point outside of the repo client 🙈.

The links are created in the order they are specified in the manifests. If multiple elements specify the same source and destination, they will only be applied as one, based on the first occurence. Links are created after any files specified via copyfile elements are copied.

💜 Element remove-project 💜

Deletes a project from the internal manifest table, which possibly allows a subsequent project element in the same manifest file to replace the project with a different source. Chef's kiss.

This element is mostly useful in a local manifest file, where you can remove a project, and possibly replace it with your own definition 👑.

The project name or project path can be used to specify the remove target, meaning one of them is required. Here's the breakdown:

  • If only name is specified, all projects with that name are removed.
  • If both name and path are specified, only projects with the same name and path are removed — so projects with the same name but in other locations are kept 🫶.
  • If only path is specified, a matching project is removed regardless of its name. Logic otherwise behaves like both are specified.
  • optional — set it to true to ignore remove-project elements with no matching project element. No drama, no error 💅.
  • base-rev — if specified, adds a check against the revision to be removed. Manifest parse will fail and give a list of mismatch removes if the revisions being removed have changed since base-rev was set. Intended for use with layered manifests using hash revisions to prevent patch branches hiding newer upstream revisions. Also compares named refs like branches or tags but is misleading if branches are used as base-rev. Same syntax as the corresponding element of project.

🍓 Element repo-hooks 🍓

NB 🔔: See the practical documentation at ./repo-hooks.md for using repo hooks.

Only one repo-hooks element may be specified at a time. Attempting to redefine it will fail to parse. One. Singular. That's the rule 💀.

  • in-project — the project where the hooks are defined. The value must match the name attribute (not the path attribute) of a previously defined project element. read that again: not the path 👀.
  • enabled-list — list of hooks to use, whitespace or comma separated.

🌈 Element superproject 🌈

* Note: This is currently a WIP. *

NB 🔔: See the git superprojects documentation at https://en.wikibooks.org/wiki/Git/Submodules_and_Superprojects for background information.

This element is used to specify the URL of the superproject. It has name and remote as attributes. Only name is required while the others have reasonable defaults. At most one superproject may be specified — attempting to redefine it will fail to parse.

  • name — a unique name for the superproject. This attribute has the same meaning as project's name attribute. See the element project for more information.
  • remote — name of a previously defined remote element. If not supplied, the remote given by the default element is used.
  • revision — name of the Git branch the manifest wants to track for this superproject. If not supplied, the revision given by the remote element is used if applicable, else the default element is used.

🧚 Element contactinfo 🧚

* Note: This is currently a WIP. *

This element is used to let manifest authors self-register contact info ✨. It has bugurl as a required attribute. This element can be repeated, and any later entries will clobber earlier ones. This would allow manifest authors who extend manifests to specify their own contact info 💅.

  • bugurl — the URL to file a bug against the manifest owner.

⭐ Element include ⭐

This element provides the capability of including another manifest file into the originating manifest. Normal rules apply for the target manifest to include — it must be a usable manifest on its own 💯.

  • name — the manifest to include, specified relative to the manifest repository's root.

name may not be an absolute path or use . or .. path components. These restrictions are not enforced for Local Manifests, though 👀.

  • groups — set of additional groups to which all projects in the included manifest belong. This appends and recurses, meaning all projects in included manifests carry all parent include groups. This also applies to all extend-project elements in the included manifests. Same syntax as the corresponding element of project 🎀.
  • revision — name of a Git branch (e.g. main or refs/heads/main) default to which all projects in the included manifest belong. This recurses, meaning it will apply to all projects in all manifests included as a result of this element. It goes all the way down, bestie 💜.

👑 Local Manifests 👑

Additional remotes and projects may be added through local manifest files stored in $TOP_DIR/.repo/local_manifests/*.xml 🗂️.

For example:

$ ls .repo/local_manifests

local_manifest.xml another_local_manifest.xml

$ cat .repo/local_manifests/local_manifest.xml

<?xml version="1.0" encoding="UTF-8"?> <manifest>

<project path="manifest"

name="tools/manifest" />

<project path="platform-manifest"

name="platform/manifest" />

</manifest>

Users may add projects to the local manifest(s) prior to a repo sync invocation, instructing repo to automatically download and manage these extra projects ✨.

Manifest files stored in $TOP_DIR/.repo/local_manifests/*.xml will be loaded in alphabetical order. So yes, naming is destiny.

Projects from local manifest files are added into the local::<local manifest filename> group 💅.

⚠️ heads up: The legacy $TOP_DIR/.repo/local_manifest.xml path is no longer supported. It's giving deprecated. Do not. 🚫

Also, for the completionists out there, the reference links sprinkled through this page resolve to these targets 👇

  • [copyfile]: #Element-copyfile
  • [linkfile]: #Element-linkfile
  • [Local Manifests]: #local-manifests

And that's a wrap on REPO(1) 💖 this whole thing is from the repo manifest page, dated August 2026, living in section 1 of the manual. go forth and sync, bestie 🌈✨👑

📦 where this page comes from