pdk/docs/source/git-repo.jd - platform/development - Git at Google

 page.title=Using Repo and Git
 doc.type=source
 @jd:body
 <div>
 <p>To work with the Android code, you will need to use both Git and Repo.<br></p>
 <ul><li><i>Git</i>
 is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits.<br><br></li>
 <li><i>Repo</i>
 is a tool that we built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our <a href="http://review.source.android.com/">revision control system</a>
 , and automates parts of the Android development workflow. Repo is not meant to replace Git, only to make it easier to work with Git in the context of Android. The repocommand is an executable Python script that you can put anywhere in your path.<i><br><br></i>
 In working with the Android source files, you will use Repo for across-network operations. For example, with a single Repo command you can download files from multiple repositories into your local working directory.
 </li>
 </ul>
 <h2>
 About Git
 </h2>
 <h3>
 Why Git?
 </h3>
 One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.<br><h3>
 Already a Git user?
 </h3>
 In most situations, you can use Git instead of Repo, or mix Repo and Git
 commands to form complex commands. Using Repo for basic across-network
 operations will make your work much simpler, however.
 <br>
 <div><h2>
 Task reference <br></h2>
 The task list below shows a summary of how to do common Repo and Git tasks.
 For complete quick-start information and examples, see <a
 href="{@docRoot}source/download.html">Get source</a>
 .
 <h3>
 Installing Repo <br></h3>
 $ curl http://android.git.kernel.org/repo &gt; ~/bin/repo <div>$ chmod a+x ~/bin/repo</div>
 $ mkdir <i>working-directory-name</i>
 <br>$ cd <i>working-directory-name <br></i>
 $ repo init -u git://android.git.kernel.org/platform/manifest.git <br><br><h3>
 Synchronizing your client
 </h3>
 To synchronize the files for all available projects:<br>$ repo sync <br><br>To
 synchronize the files for selected projects:<br>$ repo sync <i>project1
 project2 ...</i>
 <i><br></i>
 <br><h3>
 Why use topic branches?
 </h3>
 Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature.<br><br>A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you canisolateone aspect of your work from the others. For an interesting article about using topic branches, see <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt">Separating topic branches</a>
 .
 <div><img src="{@docRoot}images/git-repo-0.png">
 </div>
 <br><br><h3>
 Creating topic branches
 </h3>
 To start a topic branch using Repo:<br>$ repo start <i>branchname</i>
 <br><br>To verify that your new branch was created:<br>$ repo status <br><br><h3>
 Using topic branches
 </h3>
 To assign the branch to a particular project:<br>$ repo start <i>branch</i>
 <i>name project</i>
 <br><br>To switch back and forth among branches that you have created in your local work environment:<br>$ git checkout <i>branchname</i>
 <br><br>To see a list of existing branches:<br>$ git branch <br>or...<br>$ repo branches <br><br>The name of the current branch will be preceded by an asterisk.<br><br></div>
 <div><i><b>Note:</b>
 <br></i>
 A bug might be causing repo sync to reset the local topic branch. If git branch shows * (no branch) after you run repo sync, then run git checkoutagain.<br></div>
 <div><br><h3>
 Viewing client status
 </h3>
 To list the state of your files:<br>$ repo status <br><br>To see uncommitted edits:<br>$ repo diff <br><br>Therepo diffcommand shows every local edit that you have made that would <i>not</i>
 go into the commit, if you were to commit right now.<br><br>To see every edit that would go into the commit if you were to commit right now, you need a Git command, git diff. Before running it, be sure you are down in the project directory:<br>$ cd ~/<i>workingdirectory</i>
 /<i>project</i>
 <br>$ git diff --cached <br><br><h3>
 Recovering sync conflicts
 </h3>
 If a repo sync shows sync conflicts:<br><ol><li>View the files that are unmerged (status code = U).
 </li>
 <li>Edit the conflict regions as necessary.
 </li>
 <li>Change into the relevant project directory, run git add and git commit for the files in question, and then "rebase" the changes. For example:<br>$ cd bionic <br>$ git add bionic/*<br>$ git commit <br>$ git rebase --continue <br><br></li>
 <li>When the rebase is complete start the entire sync again:<br>$ repo syncbionic <i>proj2</i>
 <i>proj3</i>
 <i>...</i>

 <i>projN</i>
 <br></li>
 </ol>
 <h3>
 Cleaning up your client files <br></h3>
 To update your local working directory after changes are merged in Gerrit:<br>$repo sync <br><br>To safely remove stale topic branches:<br>$ repo prune <br><br><h3>
 Deleting a client
 </h3>
 Deleting a client will <b>permanently delete</b>
 any changes you have not yet uploaded for review.Becauseall state information is stored in your client, you only need to delete the directory from your filesystem:<br><br>$ cd <i>~</i>
 <br>$ rm -rf <i>working-directory-name</i>
 <br><br><h3>
 Scripting common tasks
 </h3>
 You can use Repo to run the same program across all projects:<br><br>$ repo forall[<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]-c '<i>echo $REPO_PROJECT $@</i>
 '[<i>arg1</i>
 <i>arg2</i>
 <i>...</i>

 <i>argN</i>
 ]<br><br>The -c argument is evaluated through /bin/sh and any arguments after it are passed through as shell positional parameters.<br><br><h2>
 Repo command reference
 </h2>
 Repo usage takes the following form:<br>repo <i>command options</i>
 <br><br>Optional elements are shown in brackets[ ]. Once Repo is installed, you can get information about any command by running <br>repo help <i>command</i>
 <br><br><h3>
 init
 </h3>
 repo init -u <i>url</i>
 [<i>options</i>
 ]<br><br><div>Installs Repo in the current directory. This creates a .repo/ directory that contains Git repositories for the Repo source code and the standard Android manifest files. The .repo/ directory also containsmanifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.<br><br>The -u argument specifies a URL from which to retrieve a manifest repository. For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git <br><br>To select a manifest file within the repository, use the -m option. (If no manifest name is selected, the default is default.xml.)For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git-m dalkvik-plus.xml <br><br>To specify a revision, that is, a particular manifest-branch, use the -b option. For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git-b release-1.0<br><br>To see other repo init options, run <br>$ repo help init <br><br><b>Note:</b>
 For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.<br><br></div>
 <h3>
 sync
 </h3>
 repo sync [<i>project-list</i>
 ]<br><br><div>Downloads new changes and updates the working files in your local environment. After a successful repo sync, the code in specified projects will be up to date with the code in the remote repository.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo sync [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br><br>If you run repo sync without any arguments, it will synchronize the files for all the projects.<br><br></div>
 <p><b>How Repo synchronization works</b>
 <br></p>
 <div>When you run repo sync, this is what happens:<br></div>
 <ol><li>If the project has never been synchronized, then repo sync is equivalent to git clone. All branches in the remote repository are copied to the local project directory.
 </li>
 <li>If the project has already been synchronized once, then repo sync is equivalent to:<br>git remote update <br>git rebase origin/<i>branch</i>
 <br>where <i>branch</i>
 is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.<br><br>If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, git rebase --continue) to resolve the conflicts.<br></li>
 </ol>
 <div>The repo sync command also updates the private repositories in the .repo/ directory.<br></div>
 <br><h3>
 upload
 </h3>
 repo upload [<i>project-list</i>
 ]<br><br><div>For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.<br><br>After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization.Visit <a href="http://review.source.android.com/Gerrit#settings,ssh-keys">SSH Keys</a>
 within the user settings panel to register your public keys with Gerrit.To enable password-less uploads, consider using ssh-agent on your client system.<br><br>When Gerrit receives the object data over its SSH server, it will turn each commit into a change so that reviewers can comment on each commit individually.<br><br>To combine several "checkpoint" commits together into a single commit, use git rebase -i before you run repo upload.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo upload [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br><br>If you run repo upload without any arguments, it will search all the projects for changes to upload.<br><br>To make edits to changes after they have been uploaded, you should use a tool likegit rebase -ior git commit --amend to update your local commits.<br><br>After your edits are complete:<br></div>
 <div><ol><li>Make sure the updated branch is the currently checked out branch.
 </li>
 <li>Use repo upload --replace <i>proj1</i>
 to open the change matching editor.
 </li>
 <li>For each commit in the series, enter the Gerrit change Id inside the brackets:<br></li>
 </ol>
 </div>
 <div># Replacing from branch foo <br>[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...<br>[ 2829 ] ec18b4ba Update proto client to support patch set replacments <br>[ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...<br># Insert change numbers in the brackets to add a new patch set.<br># To create a new change record, leave the brackets empty.<br><br>After the upload is complete the changes will have an additional Patch Set (e.g. Patch Set 2, Patch Set 3, ...).<br></div>
 <br><h3>
 diff
 </h3>
 repo diff [<i>project-list</i>
 ]<br><br><div>Shows changes between commit and working tree.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo diff [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br><br>Options:<br>-h, --helpmeans show this help message and exit.<br></div>
 <br><h3>
 download <br></h3>
 repo download <i>target</i>
 <i>change</i>
 <br><br><div>Downloads the specified change into the specified local directory. (Added to Repo as of version 1.0.4.)<br><br>For example, to download <a href="http://review.source.android.com/1241">change 1241</a>
 into your platform/frameworks/base directory:<br>$ repo download platform/frameworks/base 1241<br><br>A"repo sync"should effectively remove any commits retrieved via "repo download".Or, you can check out the remote branch; e.g., "git checkout m/master".<br><br><b>Note:</b>
 As of Jan. 26, 2009, there is a mirroring lag of approximately 5 minutes between when a change is visible on the web in <a href="http://review.source.android.com/">Gerrit</a>
 and when repo download will be able to find it, because changes are actually downloaded off the git://android.git.kernel.org/ mirror farm. There will always be a slight mirroring lag as Gerrit pushes newly uploaded changes out to the mirror farm.
 </div>
 <br><h3>
 forall
 </h3>
 repo forall [<i>project-list</i>
 ] -c <i>command</i>
 [<i>arg.</i>
 ..]<br><br><div>Runs a shell command in each project.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects <br></div>
 <br><h3>
 help
 </h3>
 repo help [<i>command</i>
 ]<br><br><div>Displays detailed help about a command.<br></div>
 <br><h3>
 prune <br></h3>
 repo prune [<i>project-list</i>
 ]<br><br><div>Prunes (deletes) topics that are already merged.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo prune [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br></div>
 <br><h3>
 start
 </h3>
 repo start <i>newbranchname</i>
 [<i>project-list</i>
 ]<br><br><div>Starts a new branch for development.<br><br>The <i>newbranchname</i>
 argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.<br><br>The <i>project-list</i>
 specifies which projects will participate in this topic branch. You can specify project-list as a list of names or a list of paths to local working directories for the projects:<br>repo start default [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br><br>"." is a useful shorthand for the project in the current working directory.<br></div>
 <br><h3>
 status
 </h3>
 repo status [<i>project-list</i>
 ]<br><br><div>Shows the status of the current working directory. You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo status [<i>proj1</i>
 <i>proj2</i>
 <i>...</i>

 <i>projN</i>
 ]<br><br>To see the status for only the current branch, run <br>repo status .<br><br>The status information will be listed by project. For each file in the project, a two-letter code is used:<br></div>
 <div><ul><li>In the left-most column, an uppercase letter indicates what is happening in the index (the staged files) when compared to the last committed state.<br><br></li>
 <li>In the next column, a lowercase letter indicates what is happening in the working directory when compared to the index (what is staged).
 </li>
 </ul>
 <table><tbody><tr><td><b>Character</b>
 </td>
 <td><b>Meaning</b>
 </td>
 </tr>
 <tr><td>A
 </td>
 <td>The file is added (brand new). Can only appear in the first column.<br></td>
 </tr>
 <tr><td>M or m <br></td>
 <td>The file already exists but has been modified in some way.
 </td>
 </tr>
 <tr><td>D or d <br></td>
 <td>The file has been deleted.<br></td>
 </tr>
 <tr><td>R
 </td>
 <td>The file has been renamed. Can only appear in the first column. The new name is also shown on the line.</td>
 </tr>
 <tr><td>C
 </td>
 <td>The file has been copied from another file. Can only appear in the first column. The source is also shown.
 </td>
 </tr>
 <tr><td>T
 </td>
 <td>Only the file's mode (executable or not) has been changed. Can only appear in the first column.
 </td>
 </tr>
 <tr><td>U
 </td>
 <td>The file has merge conflicts and is still unmerged. Can only appear in the first column.
 </td>
 </tr>
 <tr><td>-
 </td>
 <td>The file state is unmodified. A hyphen in <i>both</i>
 columns means this is a new file, unknown to Git. After you run git add on this file, repo status will show A-, indicating the file has been added.<br></td>
 </tr>
 </tbody>
 </table>
 <br>For example, if you edit the file main.py within the appeng project without staging the changes, then repo status might show <br><br>project appeng/<br>-mmain.py <br><br>If you go on to stage the changes to main.py by running git add, then repo status might show <br><br>project appeng/<br>M- main.py <br><br>If you then make further edits to the already-staged main.py and make edits to another file within the project, app.yaml, then repo status might show <br><br>project appeng/<br>-mapp.yaml <br>Mm main.py <br><br></div>
 <h2>
 Git and Repo cheatsheet
 </h2>
 Click on the cheatsheet to open it in a new window for easier printing.

 <div><img src="{@docRoot}images/git-repo-1.png">
 </div>

 <!--
 <h2>Additional Resources</h2>
 <h3>Resources for platform developers</h3>
 Google I/O videos:
 <ul>
   <li><a href="http://sites.google.com/site/io/an-introduction-to-android">Introduction to Android</a></li>
   <li><a href="http://sites.google.com/site/io/anatomy-physiology-of-an-android">Anatomy Physiology of an Android</a></li>
   <li><a href="http://sites.google.com/site/io/inside-the-android-application-framework">Inside the Android Application Framework</a></li>
   <li><a href="http://sites.google.com/site/io/dalvik-vm-internals">Dalvik VM Internals</a></li>
 </ul>

 Getting started with the Android source code:
 <ul>
   <li><a href="http://source.android.com/source/download.html">Get source</a></li>
   <li><a href="http://source.android.com/source/code-style.html">Code Style Guide</a></li>
 </ul>

 Repo and Git resources:
 <ul>
   <li><a href="http://source.android.com/source/git-repo.html">Using Repo and Git</a></li>
   <li>The <a href="http://book.git-scm.com/">Git Community Book</a> maintained by Scott Chacon</li>
   <li><a href="http://git.or.cz/gitwiki/FrontPage">GitWiki</a></li>
   <li><a href="http://www.kernel.org/pub/software/scm/git/docs/">Git Manual Page</a></li>
   <li><a href="http://www.gitcasts.com/">GitCasts</a> (Git how-to videos)</li>
 </ul>

 Documentation on specific tasks:
 <ul>
   <li><a href="http://source.android.com/source/building-dream.html">Building for an Android Developer Phone</a></li>
 </ul>
 -->

 <h2>
 <b>Terminology</b>
 </h2>
 <i>Staged</i>
 <i>changes</i>
 <br>Changes marked by git add for inclusion in the next commit's snapshot.<br><br><i>Commit <br></i>
 At intervals, you use git commit to save a snapshot of the staged files and a log message that describes the change.<br><br><i>Manifest</i>
 <br>A manifest file that contains a list of repositories and a mapping of where the files from these repositories will be located within your working directory. When you synchronize your files, the files contained in the repositories that are listed in the manifest will be pulled into your working directory.</div>
 </div>
	page.title=Using Repo and Git
	doc.type=source
	@jd:body
	<div>
	<p>To work with the Android code, you will need to use both Git and Repo.<br></p>
	<ul><li><i>Git</i>
	is an open-source version-control system designed to handle very large projects that are distributed over multiple repositories. In the context of Android, we use Git for local operations such as local branching, commits, diffs, and edits.<br><br></li>
	<li><i>Repo</i>
	is a tool that we built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our <a href="http://review.source.android.com/">revision control system</a>
	, and automates parts of the Android development workflow. Repo is not meant to replace Git, only to make it easier to work with Git in the context of Android. The repocommand is an executable Python script that you can put anywhere in your path.<i><br><br></i>
	In working with the Android source files, you will use Repo for across-network operations. For example, with a single Repo command you can download files from multiple repositories into your local working directory.
	</li>
	</ul>
	<h2>
	About Git
	</h2>
	<h3>
	Why Git?
	</h3>
	One of the challenges in setting up the Android project was figuring out how to best support the outside community--from the hobbiest community to large OEMs building mass-market consumer devices. We wanted components to be replaceable, and we wanted interesting components to be able to grow a life of their own outside of Android. We first chose a distributed revision control system, then further narrowed it down to Git.<br><h3>
	Already a Git user?
	</h3>
	In most situations, you can use Git instead of Repo, or mix Repo and Git
	commands to form complex commands. Using Repo for basic across-network
	operations will make your work much simpler, however.
	<br>
	<div><h2>
	Task reference <br></h2>
	The task list below shows a summary of how to do common Repo and Git tasks.
	For complete quick-start information and examples, see <a
	href="{@docRoot}source/download.html">Get source</a>
	.
	<h3>
	Installing Repo <br></h3>
	$ curl http://android.git.kernel.org/repo > ~/bin/repo <div>$ chmod a+x ~/bin/repo</div>
	$ mkdir <i>working-directory-name</i>
	<br>$ cd <i>working-directory-name <br></i>
	$ repo init -u git://android.git.kernel.org/platform/manifest.git <br><br><h3>
	Synchronizing your client
	</h3>
	To synchronize the files for all available projects:<br>$ repo sync <br><br>To
	synchronize the files for selected projects:<br>$ repo sync <i>project1
	project2 ...</i>
	<i><br></i>
	<br><h3>
	Why use topic branches?
	</h3>
	Start a topic branch in your local work environment whenever you begin a change, for example when you begin work on a bug or new feature.<br><br>A topic branch is not a copy of the original files; it is a pointer to a particular commit. This makes creating local branches and switching among them a light-weight operation. By using branches, you canisolateone aspect of your work from the others. For an interesting article about using topic branches, see <a href="http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt">Separating topic branches</a>
	.
	<div><img src="{@docRoot}images/git-repo-0.png">
	</div>
	<br><br><h3>
	Creating topic branches
	</h3>
	To start a topic branch using Repo:<br>$ repo start <i>branchname</i>
	<br><br>To verify that your new branch was created:<br>$ repo status <br><br><h3>
	Using topic branches
	</h3>
	To assign the branch to a particular project:<br>$ repo start <i>branch</i>
	<i>name project</i>
	<br><br>To switch back and forth among branches that you have created in your local work environment:<br>$ git checkout <i>branchname</i>
	<br><br>To see a list of existing branches:<br>$ git branch <br>or...<br>$ repo branches <br><br>The name of the current branch will be preceded by an asterisk.<br><br></div>
	<div><i><b>Note:</b>
	<br></i>
	A bug might be causing repo sync to reset the local topic branch. If git branch shows * (no branch) after you run repo sync, then run git checkoutagain.<br></div>
	<div><br><h3>
	Viewing client status
	</h3>
	To list the state of your files:<br>$ repo status <br><br>To see uncommitted edits:<br>$ repo diff <br><br>Therepo diffcommand shows every local edit that you have made that would <i>not</i>
	go into the commit, if you were to commit right now.<br><br>To see every edit that would go into the commit if you were to commit right now, you need a Git command, git diff. Before running it, be sure you are down in the project directory:<br>$ cd ~/<i>workingdirectory</i>
	/<i>project</i>
	<br>$ git diff --cached <br><br><h3>
	Recovering sync conflicts
	</h3>
	If a repo sync shows sync conflicts:<br><ol><li>View the files that are unmerged (status code = U).
	</li>
	<li>Edit the conflict regions as necessary.
	</li>
	<li>Change into the relevant project directory, run git add and git commit for the files in question, and then "rebase" the changes. For example:<br>$ cd bionic <br>$ git add bionic/*<br>$ git commit <br>$ git rebase --continue <br><br></li>
	<li>When the rebase is complete start the entire sync again:<br>$ repo syncbionic <i>proj2</i>
	<i>proj3</i>
	<i>...</i>

	<i>projN</i>
	<br></li>
	</ol>
	<h3>
	Cleaning up your client files <br></h3>
	To update your local working directory after changes are merged in Gerrit:<br>$repo sync <br><br>To safely remove stale topic branches:<br>$ repo prune <br><br><h3>
	Deleting a client
	</h3>
	Deleting a client will <b>permanently delete</b>
	any changes you have not yet uploaded for review.Becauseall state information is stored in your client, you only need to delete the directory from your filesystem:<br><br>$ cd <i>~</i>
	<br>$ rm -rf <i>working-directory-name</i>
	<br><br><h3>
	Scripting common tasks
	</h3>
	You can use Repo to run the same program across all projects:<br><br>$ repo forall[<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]-c '<i>echo $REPO_PROJECT $@</i>
	'[<i>arg1</i>
	<i>arg2</i>
	<i>...</i>

	<i>argN</i>
	]<br><br>The -c argument is evaluated through /bin/sh and any arguments after it are passed through as shell positional parameters.<br><br><h2>
	Repo command reference
	</h2>
	Repo usage takes the following form:<br>repo <i>command options</i>
	<br><br>Optional elements are shown in brackets[ ]. Once Repo is installed, you can get information about any command by running <br>repo help <i>command</i>
	<br><br><h3>
	init
	</h3>
	repo init -u <i>url</i>
	[<i>options</i>
	]<br><br><div>Installs Repo in the current directory. This creates a .repo/ directory that contains Git repositories for the Repo source code and the standard Android manifest files. The .repo/ directory also containsmanifest.xml, which is a symlink to the selected manifest in the .repo/manifests/ directory.<br><br>The -u argument specifies a URL from which to retrieve a manifest repository. For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git <br><br>To select a manifest file within the repository, use the -m option. (If no manifest name is selected, the default is default.xml.)For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git-m dalkvik-plus.xml <br><br>To specify a revision, that is, a particular manifest-branch, use the -b option. For example:<br>$ repo init -u git://android.git.kernel.org/platform/manifest.git-b release-1.0<br><br>To see other repo init options, run <br>$ repo help init <br><br><b>Note:</b>
	For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.<br><br></div>
	<h3>
	sync
	</h3>
	repo sync [<i>project-list</i>
	]<br><br><div>Downloads new changes and updates the working files in your local environment. After a successful repo sync, the code in specified projects will be up to date with the code in the remote repository.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo sync [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br><br>If you run repo sync without any arguments, it will synchronize the files for all the projects.<br><br></div>
	<p><b>How Repo synchronization works</b>
	<br></p>
	<div>When you run repo sync, this is what happens:<br></div>
	<ol><li>If the project has never been synchronized, then repo sync is equivalent to git clone. All branches in the remote repository are copied to the local project directory.
	</li>
	<li>If the project has already been synchronized once, then repo sync is equivalent to:<br>git remote update <br>git rebase origin/<i>branch</i>
	<br>where <i>branch</i>
	is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.<br><br>If the git rebase operation results in merge conflicts, you will need to use the normal Git commands (for example, git rebase --continue) to resolve the conflicts.<br></li>
	</ol>
	<div>The repo sync command also updates the private repositories in the .repo/ directory.<br></div>
	<br><h3>
	upload
	</h3>
	repo upload [<i>project-list</i>
	]<br><br><div>For the specified projects, Repo compares the local branches to the remote branches updated during the last repo sync. Repo will prompt you to select one or more of the branches that have not yet been uploaded for review.<br><br>After you select one or more branches, all commits on the selected branches are transmitted to Gerrit over an SSH connection.You will need to configure an SSH key to enable upload authorization.Visit <a href="http://review.source.android.com/Gerrit#settings,ssh-keys">SSH Keys</a>
	within the user settings panel to register your public keys with Gerrit.To enable password-less uploads, consider using ssh-agent on your client system.<br><br>When Gerrit receives the object data over its SSH server, it will turn each commit into a change so that reviewers can comment on each commit individually.<br><br>To combine several "checkpoint" commits together into a single commit, use git rebase -i before you run repo upload.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo upload [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br><br>If you run repo upload without any arguments, it will search all the projects for changes to upload.<br><br>To make edits to changes after they have been uploaded, you should use a tool likegit rebase -ior git commit --amend to update your local commits.<br><br>After your edits are complete:<br></div>
	<div><ol><li>Make sure the updated branch is the currently checked out branch.
	</li>
	<li>Use repo upload --replace <i>proj1</i>
	to open the change matching editor.
	</li>
	<li>For each commit in the series, enter the Gerrit change Id inside the brackets:<br></li>
	</ol>
	</div>
	<div># Replacing from branch foo <br>[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...<br>[ 2829 ] ec18b4ba Update proto client to support patch set replacments <br>[ 3022 ] c99883fe Teach 'repo upload --replace' how to add replacement patch se...<br># Insert change numbers in the brackets to add a new patch set.<br># To create a new change record, leave the brackets empty.<br><br>After the upload is complete the changes will have an additional Patch Set (e.g. Patch Set 2, Patch Set 3, ...).<br></div>
	<br><h3>
	diff
	</h3>
	repo diff [<i>project-list</i>
	]<br><br><div>Shows changes between commit and working tree.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo diff [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br><br>Options:<br>-h, --helpmeans show this help message and exit.<br></div>
	<br><h3>
	download <br></h3>
	repo download <i>target</i>
	<i>change</i>
	<br><br><div>Downloads the specified change into the specified local directory. (Added to Repo as of version 1.0.4.)<br><br>For example, to download <a href="http://review.source.android.com/1241">change 1241</a>
	into your platform/frameworks/base directory:<br>$ repo download platform/frameworks/base 1241<br><br>A"repo sync"should effectively remove any commits retrieved via "repo download".Or, you can check out the remote branch; e.g., "git checkout m/master".<br><br><b>Note:</b>
	As of Jan. 26, 2009, there is a mirroring lag of approximately 5 minutes between when a change is visible on the web in <a href="http://review.source.android.com/">Gerrit</a>
	and when repo download will be able to find it, because changes are actually downloaded off the git://android.git.kernel.org/ mirror farm. There will always be a slight mirroring lag as Gerrit pushes newly uploaded changes out to the mirror farm.
	</div>
	<br><h3>
	forall
	</h3>
	repo forall [<i>project-list</i>
	] -c <i>command</i>
	[<i>arg.</i>
	..]<br><br><div>Runs a shell command in each project.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects <br></div>
	<br><h3>
	help
	</h3>
	repo help [<i>command</i>
	]<br><br><div>Displays detailed help about a command.<br></div>
	<br><h3>
	prune <br></h3>
	repo prune [<i>project-list</i>
	]<br><br><div>Prunes (deletes) topics that are already merged.<br><br>You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo prune [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br></div>
	<br><h3>
	start
	</h3>
	repo start <i>newbranchname</i>
	[<i>project-list</i>
	]<br><br><div>Starts a new branch for development.<br><br>The <i>newbranchname</i>
	argument should provide a short description of the change you are trying to make to the projects.If you don't know, consider using the name default.<br><br>The <i>project-list</i>
	specifies which projects will participate in this topic branch. You can specify project-list as a list of names or a list of paths to local working directories for the projects:<br>repo start default [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br><br>"." is a useful shorthand for the project in the current working directory.<br></div>
	<br><h3>
	status
	</h3>
	repo status [<i>project-list</i>
	]<br><br><div>Shows the status of the current working directory. You can specify project-list as a list of names or a list of paths to local source directories for the projects:<br>repo status [<i>proj1</i>
	<i>proj2</i>
	<i>...</i>

	<i>projN</i>
	]<br><br>To see the status for only the current branch, run <br>repo status .<br><br>The status information will be listed by project. For each file in the project, a two-letter code is used:<br></div>
	<div><ul><li>In the left-most column, an uppercase letter indicates what is happening in the index (the staged files) when compared to the last committed state.<br><br></li>
	<li>In the next column, a lowercase letter indicates what is happening in the working directory when compared to the index (what is staged).
	</li>
	</ul>
	<table><tbody><tr><td><b>Character</b>
	</td>
	<td><b>Meaning</b>
	</td>
	</tr>
	<tr><td>A
	</td>
	<td>The file is added (brand new). Can only appear in the first column.<br></td>
	</tr>
	<tr><td>M or m <br></td>
	<td>The file already exists but has been modified in some way.
	</td>
	</tr>
	<tr><td>D or d <br></td>
	<td>The file has been deleted.<br></td>
	</tr>
	<tr><td>R
	</td>
	<td>The file has been renamed. Can only appear in the first column. The new name is also shown on the line.</td>
	</tr>
	<tr><td>C
	</td>
	<td>The file has been copied from another file. Can only appear in the first column. The source is also shown.
	</td>
	</tr>
	<tr><td>T
	</td>
	<td>Only the file's mode (executable or not) has been changed. Can only appear in the first column.
	</td>
	</tr>
	<tr><td>U
	</td>
	<td>The file has merge conflicts and is still unmerged. Can only appear in the first column.
	</td>
	</tr>
	<tr><td>-
	</td>
	<td>The file state is unmodified. A hyphen in <i>both</i>
	columns means this is a new file, unknown to Git. After you run git add on this file, repo status will show A-, indicating the file has been added.<br></td>
	</tr>
	</tbody>
	</table>
	<br>For example, if you edit the file main.py within the appeng project without staging the changes, then repo status might show <br><br>project appeng/<br>-mmain.py <br><br>If you go on to stage the changes to main.py by running git add, then repo status might show <br><br>project appeng/<br>M- main.py <br><br>If you then make further edits to the already-staged main.py and make edits to another file within the project, app.yaml, then repo status might show <br><br>project appeng/<br>-mapp.yaml <br>Mm main.py <br><br></div>
	<h2>
	Git and Repo cheatsheet
	</h2>
	Click on the cheatsheet to open it in a new window for easier printing.

	<div><img src="{@docRoot}images/git-repo-1.png">
	</div>

	<!--
	<h2>Additional Resources</h2>
	<h3>Resources for platform developers</h3>
	Google I/O videos:
	<ul>
	<li><a href="http://sites.google.com/site/io/an-introduction-to-android">Introduction to Android</a></li>
	<li><a href="http://sites.google.com/site/io/anatomy-physiology-of-an-android">Anatomy Physiology of an Android</a></li>
	<li><a href="http://sites.google.com/site/io/inside-the-android-application-framework">Inside the Android Application Framework</a></li>
	<li><a href="http://sites.google.com/site/io/dalvik-vm-internals">Dalvik VM Internals</a></li>
	</ul>

	Getting started with the Android source code:
	<ul>
	<li><a href="http://source.android.com/source/download.html">Get source</a></li>
	<li><a href="http://source.android.com/source/code-style.html">Code Style Guide</a></li>
	</ul>

	Repo and Git resources:
	<ul>
	<li><a href="http://source.android.com/source/git-repo.html">Using Repo and Git</a></li>
	<li>The <a href="http://book.git-scm.com/">Git Community Book</a> maintained by Scott Chacon</li>
	<li><a href="http://git.or.cz/gitwiki/FrontPage">GitWiki</a></li>
	<li><a href="http://www.kernel.org/pub/software/scm/git/docs/">Git Manual Page</a></li>
	<li><a href="http://www.gitcasts.com/">GitCasts</a> (Git how-to videos)</li>
	</ul>

	Documentation on specific tasks:
	<ul>
	<li><a href="http://source.android.com/source/building-dream.html">Building for an Android Developer Phone</a></li>
	</ul>
	-->

	<h2>
	<b>Terminology</b>
	</h2>
	<i>Staged</i>
	<i>changes</i>
	<br>Changes marked by git add for inclusion in the next commit's snapshot.<br><br><i>Commit <br></i>
	At intervals, you use git commit to save a snapshot of the staged files and a log message that describes the change.<br><br><i>Manifest</i>
	<br>A manifest file that contains a list of repositories and a mapping of where the files from these repositories will be located within your working directory. When you synchronize your files, the files contained in the repositories that are listed in the manifest will be pulled into your working directory.</div>
	</div>