Repo is a multi-repository management tool built on Top of Git that organizes the upload and download of multiple repositories.

Repo is a multi-repository management tool built on Top of Git that organizes the upload and download of multiple repositories. Repo is a Python script written by Google that calls Git and helps us manage multiple Git repositories, upload them to our version control system, and automate some parts of the Android development workflow. Repo is not intended to replace Git, but to make it easier to use Git in an Android environment. Let’s see how Repo is used.

Install the Repo

To install Repo, you must first ensure that you have the Git tool installed and Python2.7 + installed. Here is how to install Repo on a Mac:

1. Make sure there is a bin/ directory in the home directory and that the directory is included in the path:

mkdir ~/bin
PATH=~/bin:$PATH
Copy the code

Download the Repo tool and make sure it is executable:

curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
Copy the code

Curl. Se/Windows /dl-… . But also can directly access storage.googleapis.com/git-repo-do… Copy the contents directly to ~/bin/repo for the same effect. Alternatively, if googleapis.com is inaccessible, you can use Github’s Repo address instead:

curl https://raw.githubusercontent.com/esrlabs/git-repo/stable/repo > ~/bin/repo
Copy the code

For the Linux installation process, see github.com/esrlabs/git… The README for this repository is pretty clear.

The background of the Repo

It is a good idea to familiarize yourself with Git before using Repo, and recommended information about Git is git-scm.com/book/zh/v2. Repo was originally used to manage the Android source code base, which resides in a Git code base hosted by Google. The Git code base contains metadata for the Android source code, including metadata related to the changes made to the source code and the date they were changed. The Android repository is too large and Git can’t be partially checked out. If everything is in one repository, and a development team is concerned about a widget or plug-in, they have to download such a large repository, so the Repo manages it all.

So how does a Repo manage multiple code repositories?

The composition of Repo

Repo consists of two main parts: the Repo boot script (which Google calls the Repo Launcher) and the body of the Repo command. After we initialize the Repo repository, a.repo folder will appear with the following contents:

changlinzou@mac work % exercise-l 1. ├─ manifests. XML -> Manifests/use of ├── ├─ ├─ ├─ Project ├─ ├─ Projects ├─ 5 Directories, 2 FilesCopy the code

When the repo init command is executed to initialize the repository, the repo boot script is first executed, which goes to the specified location to download the Manifest repository, along with the repo body. Once downloaded, it will be placed in the.repo directory under the current directory, where:

folder use
manifests Repository of manifest files
manifests.git Git bare repository of manifest files, with no workspace
manifest.xml This is a link file that points to your manifest file for initializing the workspace, i.emanifests/default.xml
project.list A text file containing a list of all project names
projects This folder contains the bare repository for all Git projects, and the folder hierarchy is the same as the workspace layout
repo This is the body of the repo command, which also contains the latest repo command, and is recommended

The Android sse project Manifests four major components, just like the list of the components in the project. The compile XML file contains the name of each Git project, the reversion checked, the directory checked to, and so on. The Repo uses these manifest files to retrieve each project individually, such as this manifest file:

<? The XML version = "1.0" encoding = "utf-8"? > <manifest> <remote /> <default remote="origin" revision="master" sync-j="4" /> <project /> <project /> <project /> . </manifest>Copy the code

Here is the meaning of the elements in the Repo manifest:

The element details
The manifest element Root element of the XML file
Remote element There can be one or more remote elements that specify which server changes will be submitted to when the repo Upload command is used
The default element The attributes specified in the default element are default attributes. That is, if the attribute does not exist in the project element, the attribute specified in the default element is used. Revision: The name of the Git branch. If the project element does not specify a Revision attribute, that attribute of the default element is used. Revision property values can be a Git branch, git tag, or a COMMIT ID. Sync-j: indicates the number of concurrent tasks in sync. Sync-c: If set to true, only branches specified in the Revision property of the Project element will be synchronized when code is synchronized. If no revision property is specified for the project element, the revision property of the default element is used.
Project elements One or more project elements can be specified in the XML file. Each project element describes a Git repository that needs to be pulled locally. There are a number of attributes that can be used in the Project element, and here are just a few that we use frequently. Name: the name of the Git project, path: the path of the project’s local workspace, revision: the name of the branch the project tracks. The name can be relative to the refs/heads namespace, such as master, or absolute, such as refs/heads/master. Labels or 48-bit SHA-1 values could also theoretically work. If this attribute is not provided, the Revision attribute in the default element is used.

Repo command

The following content from Google’s official documentation: source.android.com/source/usin… :

To use the Repo, follow the following format:

repo <COMMAND> <OPTIONS>
Copy the code

Optional elements are shown in square brackets []. For example, many commands use a list of items as arguments. You can specify a project list for a project as a list of names or a list of local source directory paths:

repo sync [<PROJECT0> <PROJECT1> <PROJECTN>]
repo sync [</PATH/TO/PROJECT0> ... </PATH/TO/PROJECTN>]
Copy the code

help

After the Repo is installed, you can find the latest documentation (starting with a summary of all the commands) by running the following command:

repo help
Copy the code

You can get information about a command by running the following command in the Repo tree:

repo help <COMMAND>
Copy the code

For example, the following command generates a description and a list of options for the Repo init parameter, which initializes the Repo in the current directory. (For details, see Init.)

repo help init
Copy the code

init

$ repo init -u <URL> [<OPTIONS>]
Copy the code

Install the Repo in the current directory. This creates a.repo/ directory that contains the Git code base for the repo source and standard Android manifest files. The.repo/ directory also contains manifest.xml, which is a symbolic link to the selected listings in the.repo/manifests/ directory.

Options:

  • -u: Specifies the url from which to retrieve the manifest code base. You can be inhttps://android.googlesource.com/platform/manifestFind common listings in
  • -m: Select manifest files in the code base. If no manifest name is selected, default.xml is selected by default.
  • -b: Specifies a revised version, that is, a specific manifest branch.

Note: For all remaining Repo commands, the current working directory must be a parent directory of.repo/ or a subdirectory of the corresponding parent directory.

sync

repo sync [<PROJECT_LIST>]
Copy the code

Download the new changes and update the working files in your local environment. If you run repo Sync without any parameters, the operation synchronizes the files for all projects.

After running repo Sync, the following happens:

  • If the target project has never been synchronized, repo sync is equivalent to Git clone. All branches in the remote code base are copied to the local project directory.

  • If the target project has been synchronized, repo sync is equivalent to the following command:

    git remote update
git rebase origin/<BRANCH>
Copy the code

    Where *

    * is the currently checked out BRANCH in the local project directory. If the local branch is not tracking the branch in the remote code base, no synchronization will occur for the corresponding project.

  • If git rebase operations cause merge conflicts, then you need to use a normal git command, such as git rebase –continue, to resolve the conflicts.

When repo Sync runs successfully, the code in the specified project is kept in sync with the code in the remote code base.

Options:

  • -d: Switches the specified item back to the revised version of the manifest. This option can be helpful if the project currently belongs to a topic branch but only needs a revised version of the manifest temporarily.
  • -s: synchronizes to a known good version specified by the manifest server element in the current manifest.
  • -f: Even if one item fails to be synchronized, the system will continue to synchronize other items.

upload

repo upload [<PROJECT_LIST>]
Copy the code

For a given project, the Repo compares the local branch to the remote branch that was updated when the Repo was last synced. The Repo prompts you to select one or more branches that have not yet been uploaded for review.

After you select one or more branches, all submissions on the selected branches are transferred to Gerrit over an HTTPS connection. You need to configure an HTTPS password to enable upload authorization. To generate a new username/password pair for HTTPS transport, visit the password Generator.

When Gerrit receives object data through its servers, it turns each commit into a change so that the reviewer can comment on each commit individually. To combine several “checkpoint” commits into one commit, use git rebase -i and then run repo Upload.

If you run repo Upload without any parameters, the operation searches for changes in all projects for upload.

To modify changes after they have been uploaded, you should update your local commit using a tool like git rebase -I or Git commit –amend. After the modification, perform the following operations:

  • Check to ensure that the updated branch is the currently checked out branch.

  • For each submission in the corresponding series, enter the Gerrit change ID in square brackets:

    # Replacing from branch foo
[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
[ 2829 ] ec18b4ba Update proto client to support patch set replacments
# Insert change numbers in the brackets to add a new patch set.
# To create a new change record, leave the brackets empty.
Copy the code

Once the upload is complete, these changes will have an additional patch assembly.

diff

repo diff [<PROJECT_LIST>]
Copy the code

Use git diff to show obvious changes between commits and the working tree.

download

repo download <TARGET> <CHANGE>
Copy the code

Download the specified changes from the audit system and place them in your project’s local working directory for use.

For example, to download change 23823 to your platform/build directory, run the following command:

$ repo download platform/build 23823
Copy the code

Repo Sync should effectively remove any commits retrieved through Repo Download. Alternatively, you can checkout the remote branch, such as git checkout m/master.

Note: There is a slight mirroring delay between the time a change (in Gerrit) appears on the network and the time all users can find the change through Repo Download, since all servers around the world have replication delays.

forall

repo forall [<PROJECT_LIST>] -c <COMMAND>
Copy the code

Run the specified shell command in each project. The following additional environment variables are available with repo Forall:

  • REPO_PROJECTCan be set to a unique name for the project.
  • REPO_PATHIs the relative path of the client root directory.
  • REPO_REMOTEIs the name of the remote system in the listing.
  • REPO_LREVIs the name of the revised version in the listing that has been converted to a local trace branch. You can use this variable if you need to pass a manifest revision to a locally running Git command.
  • REPO_RREVIs the name of the revised version in the listing, exactly the same as the name shown in the listing.

Options:

  • -c: Command and parameters to run. The command will pass/bin/shEvaluate, and any arguments after it are passed as shell position arguments.
  • -p: Displays item target headers before specifying command output. This is done by binding pipes to the STdin, STdout, and STERr streams of commands, and then piping all output results into a continuous stream displayed in a page scheduling session.
  • -v: displays messages written to stderr by the command.

prune

repo prune [<PROJECT_LIST>]
Copy the code

Delete (delete) merged topics.

start

repo start <BRANCH_NAME> [<PROJECT_LIST>]
Copy the code

Starting with the revised version specified in the listing, create a new branch to develop.

The *

* parameter should briefly describe the changes you are trying to make to the project. If you don’t know, consider using the default name.

* * specifies the projects that will participate in this topic branch.

Note: “.” Is a very useful shorthand for an item in the current working directory.

status

repo status [<PROJECT_LIST>]
Copy the code

For each specified project, the working tree is compared to the temporary region (index) and the last commit on this branch (HEAD). Display summary lines for each file where the three states differ.

To see only the status of the current branch, run repo Status. The system lists the status information by item. For each file in the project, the system uses a two-letter code:

In the first column, capital letters indicate the difference between the temporary region and the last committed state.

The letter meaning instructions
– There is no change HEAD is the same as in the index
A Have been added Does not exist in the HEAD, but exists in the index
M The modified Exists in HEAD, but the file in the index has been modified
D deleted Exists in the HEAD, but not in the index
R Has been renamed Does not exist in HEAD, but the path of the file in the index has changed
C replicated Does not exist in HEAD, copied from another file in index
T Schema changed HEAD is the same as in the index, but the schema has changed
U unincorporated There is a conflict between HEAD and index. Need a solution

In the second column, lowercase letters indicate the difference between the working directory and the index.

The letter meaning instructions
– New/unknown Does not exist in the index, but exists in the working tree
m The modified Exists in the index as well as in the working tree (but modified)
d deleted Exists in the index, not in the working tree

The resources

1, source.android.com/source/usin…

2, git-scm.com/book/zh/v2