It is common in command line tools to indicate what the default answer
will be if the user simply hits enter. In repo, the display is just
"y/n" with no indication as to which is the default. So change the n
to N in the messages since that is how repo operates.
Change-Id: I81819ae630355072eb0365e59168b0921289498f
An HTTP (or HTTPS) based remote server may now offer a 'clone.bundle'
file in each repository's Git directory. Over an http:// or https://
remote repo will first ask for '$URL/clone.bundle', and if present
download this to bootstrap the local client, rather than relying
on the native Git transport to initialize the new repository.
Bundles may be hosted elsewhere. The client automatically follows a
HTTP 302 redirect to acquire the bundle file. This allows servers
to direct clients to cached copies residing on content delivery
networks, where the bundle may be closer to the end-user.
Bundle downloads are resumeable from where they last left off,
allowing clients to initialize large repositories even when the
connection gets interrupted.
If a bundle does not exist for a repository (a HTTP 404 response
code is returned for '$URL/clone.bundle'), the native Git transport
is used instead. If the client is performing a shallow sync, the
bundle transport is not used, as there is no way to embed shallow
data into the bundle.
Change-Id: I05dad17792fd6fd20635a0f71589566e557cc743
Signed-off-by: Shawn O. Pearce <sop@google.com>
This is the simplest fix: if we had problems syncing the
manifest.git directory and we were the ones that created it,
we should delete it. This doesn't try to do anything complex
like try to recover from a .repo directory that got broken in
some other way.
This is filed as: <http://crosbug.com/13403>
TEST=manual
Init once with a bad URL:
$ repo init -u http://foobar.example.com
Getting manifest ...
from http://foobar.example.com
Connection closed by 172.22.121.77
error: Couldn't resolve host 'foobar.example.com' while accessing http://foobar.example.com/info/refs
fatal: HTTP request failed
fatal: cannot obtain manifest http://foobar.example.com
Init again: identical to the first. Good:
$ repo init -u http://foobar.example.com
Getting manifest ...
from http://foobar.example.com
Connection closed by 172.22.121.77
error: Couldn't resolve host 'foobar.example.com' while accessing http://foobar.example.com/info/refs
fatal: HTTP request failed
fatal: cannot obtain manifest http://foobar.example.com
Init with correct URL:
$ repo init -u http://git.chromium.org/git/manifest -m minilayout.xml
Getting manifest ...
from http://git.chromium.org/git/manifest
[ ... cut ... ]
repo initialized in /.../repoiniterr
Try a bad URL after a good one; it doesn't get saved (good):
$ repo init -u http://foobar.example.com
Connection closed by 172.22.121.77
error: Couldn't resolve host 'foobar.example.com' while accessing http://foobar.example.com/info/refs
fatal: HTTP request failed
fatal: cannot obtain manifest http://foobar.example.com
Just to confirm, I can still do a good one after a bad...
$ repo init -u http://git.chromium.org/git/manifest -m minilayout.xml
Your Name [George Washington]:
Your Email [george@washington.example.com]:
Your identity is: George Washington <george@washington.example.com>
is this correct [y/n]? y
repo initialized in /.../repoiniterr
Change-Id: I1692821a330d97b1d218b2e191a93245b33f2362
Use git clone to initialize a new repository, and when possible
allow callers to use --reference to reuse an existing checkout as
the initial object storage area for the new checkout.
Change-Id: Ie27f760247f311ce484c6d3e85a90d94da2febfc
Signed-off-by: Shawn O. Pearce <sop@google.com>
When someone copies and pastes a setup line from a web page,
they might actually copy 'repo sync' onto the clipboard and wind
up pasting it into the "Your Name" prompt. This means they will
initialize their client with the user name of "repo sync", creating
some rather funny looking commits later on. For example:
To setup your source tree:
mkdir ~/code
cd ~/code
repo init -u git://....
repo sync
If this entire block was just blindly copy and pasted into the
terminal, the shell won't read "repo sync" but "repo init" will.
By showing the user their full identity string, and asking them
to confirm it before we continue, we can give the hapless user a
chance to recover from this mistake, without unfairly harming those
who were actually named 'repo' by their parents.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way we can use it to detect feature support in the underlying
git, such as new options or commands that have been added in more
recent versions.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The revisionExpr field now holds an expression from the manifest,
such as "refs/heads/master", while revisionId holds the current
commit-ish SHA-1 of the revisionExpr. Currently that is only
filled in if the manifest points directly to a SHA-1.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now feed Project a RemoteSpec, instead of the Remote directly
from the XmlManifest. This way the RemoteSpec already has the
full project URL, rather than just the base, permitting other
types of manifests to produce the URL in their own style.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now try to sync all projects that can be done safely first, before
we start rebasing user commits over the upstream. This has the nice
effect of making the local tree as close to the upstream as possible
before the user has to start resolving merge conflicts, as that extra
information in other projects may aid in the conflict resolution.
Informational output is buffered and delayed until calculation for
all projects has been done, so that the user gets one concise list
of notice messages, rather than it interrupting the progress meter.
Fast-forward output is now prefixed with the project header, so the
user can see which project that update is taking place in, and make
some relation of the diffstat back to the project name.
Rebase output is now prefixed with the project header, so that if
the rebase fails, the user can see which project we were operating
on and can try to address the failure themselves.
Since rebase sits on a detached HEAD, we now look for an in-progress
rebase during sync, so we can alert the user that the given project
is in a state we cannot handle.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If `repo start foo` fails due to uncommitted and unmergeable changes
in a single project, we have switched half of the projects over to
the new target branches, but didn't on the one that failed to move.
This change improves the situation by doing three things differently:
- We keep going when we encounter an error, so other projects
that can successfully switch still switch.
- We ignore projects whose current branch is already on the
requested name; they are logically already setup.
- We checkout the branch if it already exists, rather than
trying to recreate the branch.
Bug: REPO-22
Signed-off-by: Shawn O. Pearce <sop@google.com>
On a mirror client we don't prompt for user.name,user.email as the
data is only necessary if you will make new commits. On a re-init
we were testing the command line option, not the existing IsMirror
property from the manifest configuration file.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This allows the user to run "repo init -u" again after an
initial attempt failed due to an invalid URL.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Instead of a stack trace ending in origin/master not existing we
now tell the user the manifest url is invalid if 'git fetch' has
failed out early.
Signed-off-by: Shawn O. Pearce <sop@google.com>
We now correctly support re-initializing an existing client to point
to a different branch of the same manifest repository, effectively
allowing the client to switch the baseline it is operating on.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Simply setting repo.mirror true doesn't make a client into a mirror.
The on-disk layout is completely wrong for a mirror repository,
and until we fix our layout for a non-mirror client to more closely
resemble the upstream we can't do anything to easily turn on or
turn off the mirror status flag.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If a client was created with "repo init --mirror" then there are
no working directories present, and no files checked out. Using
a command like "repo status" in this context makes no sense, and
actually throws back a Pytyon traceback at the console when the
underlying commands fail out.
We now tag commands with the MirrorSafeCommand type if they are
able to be executed within a mirror directory safely. Using a
command in a mirror which lacks this base class results in a
useful error letting you know the command isn't supported.
Bug: REPO-14
Signed-off-by: Shawn O. Pearce <sop@google.com>
The mirror option downloads a complete forrest (as described by the
manifest) and creates a replica of the remote repositories rather
than a client working directory. This permits other clients to
sync off the mirror site.
A mirror can be positioned in a "DMZ", where the mirror executes
"repo sync" to obtain changes from the external upstream and
clients inside the protected zone operate off the mirror only,
and therefore do not require direct git:// access to the external
upstream repositories.
Signed-off-by: Shawn O. Pearce <sop@google.com>
