Whatever branch name we checked the manifest out from is the name
we want to reflect throughout the rest of the projects, e.g. within
the special "m/" remote space.
This reduces the difference between different branches within the
manifest file.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Prior to open-sourcing repo we had manifests in two different
layouts; one where the manifest was a straight-up git clone, and
one where the manifest was our bare repository with symlink work
tree format (identical to what our projects use). Only the latter
form is created or used by repo at this point, so the transition
code to handle the straight-up git clone is not necessary.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Now that repo relies only on the git data stream (as it is much
faster to download through) we don't really need to be parsing the
<snapshot> elements within manifest. Its a lot of complex code to
convert the tar (or zip) through to a fast import stream, and we
just aren't calling it anymore.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way we can build more than one Manifest instance in memory
and not muck around with the Editor configuration each time we
build a new instance.
Signed-off-by: Shawn O. Pearce <sop@google.com>
By creating a .repo/local_manifest.xml the user can add extra
projects into their client space, without touching the main
manifest script.
For example:
$ cat .repo/local_manifest.xml
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project path="android-build"
name="platform/build"
remote="korg"
revision="android-1.0" />
</manifest>
Signed-off-by: Shawn O. Pearce <sop@google.com>
