Commit Graph

20 Commits

Author SHA1 Message Date
Doug Anderson
30d452905f Add a --depth option to repo init.
Change-Id: Id30fb4a85f4f8a1847420b0b51a86060041eb5bf
2011-06-09 16:48:23 -07:00
Doug Anderson
2630dd9787 Fixed problems w/ 2nd repo init if first repo init had bad URL.
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
2011-04-07 16:51:50 -04:00
Shawn O. Pearce
88443387b1 sync: Enable use of git clone --reference
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>
2010-10-29 12:08:50 -07:00
Nico Sallembien
6d7508b3d5 Allow 'y' as a valid response when confirming identity
I prefer having to type only one character rather than all three,
and it seems like other confirmation prompts use the same style.
2010-04-01 11:30:56 -07:00
Shawn O. Pearce
37dbf2bf0f Try to prevent 'repo sync' as a user name
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>
2009-07-02 10:53:04 -07:00
Shawn O. Pearce
2ec00b9272 Refactor git version detection for reuse
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>
2009-06-12 09:32:50 -07:00
Shawn O. Pearce
3c8dea1f8d Change project.revision to revisionExpr and revisionId
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>
2009-05-29 18:45:20 -07:00
Shawn O. Pearce
d1f70d9929 Refactor how projects parse remotes so it can be replaced
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>
2009-05-29 09:31:28 -07:00
Shawn O. Pearce
77bb4af241 Improve the help text for 'repo init'
Signed-off-by: Shawn O. Pearce <sop@google.com>
2009-04-18 11:33:32 -07:00
Shawn O. Pearce
fd89b67f5c Clarify options that control the repo executable version
Signed-off-by: Shawn O. Pearce <sop@google.com>
2009-04-18 11:28:57 -07:00
Shawn O. Pearce
350cde4c4b Change repo sync to be more friendly when updating the tree
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>
2009-04-16 11:21:18 -07:00
Shawn O. Pearce
0a389e94de Make 'repo start' restartable upon failures
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>
2009-04-10 16:21:18 -07:00
Shawn O. Pearce
8630f39dba Fix repo re-init in a mirror to not prompt
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>
2009-03-19 10:17:12 -07:00
Shawn O. Pearce
df01883f9b Allow repo init to restart if URL was initially invalid
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>
2009-03-17 08:15:27 -07:00
Shawn O. Pearce
1fc99f4e47 Give a more friendly error in 'repo init' if manifest url is invalid
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>
2009-03-17 08:11:51 -07:00
Shawn O. Pearce
521cd3ce67 Support "repo init -b foo && repo sync" to switch baselines
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>
2009-03-09 18:53:20 -07:00
Shawn O. Pearce
5470df6219 Don't permit "repo init --mirror" in an existing client
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>
2009-03-09 18:51:58 -07:00
Shawn O. Pearce
c95583bf4f Don't permit users to run repo status in a mirror client
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>
2009-03-03 17:47:06 -08:00
Shawn O. Pearce
e284ad1d1a Add 'repo init --mirror' to download a complete forrest
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>
2008-11-05 18:08:32 -08:00
The Android Open Source Project
cf31fe9b4f Initial Contribution 2008-10-21 07:00:00 -07:00