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>
Git may have been installed without its hooks directory, which
means we won't have any hooks in a repo created git repository.
Since we are just deleting the hooks it doesn't matter.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Downloading and streaming a tar into Git is slower than just
letting the native git:// protocol handle the data transfer,
especially when there are multiple revisions available and
Git can perform delta compression across revisions.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Hiding error messages from the remote peer is not a good idea,
as users should be made aware when the remote peer is not a
complete Git repository so they can alert the administrators
and have the repository corrected.
Signed-off-by: Shawn O. Pearce <sop@google.com>
The initial open source release of the Android 1.0 platform had
some problems with its Perforce->Git imports. Google was forced
to rewrite some history to redirect users onto more stable upstream
sources and correct errors in the imports.
Not everyone has the correct android-1.0 tags, as some users did
manage to fetch the platform early, before the mirror sites crashed
and the history was rewritten.
This change is a band-aid to ensure any stale android-1.0 tags are
get updated to the corrected version. It should be backed out at
some point in the near future, when we can be fairly certain that
everyone has the correct android-1.0 tags.
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>
Now `repo download . 1402` would download the change numbered 1402
into the current project and check it out for the user, using a
detached HEAD. `repo sync .` would back out of the change and
return to the upstream version.
Multiple projects can be fetched at once by listing them out on
the command line as different arguments.
Individual patch sets can be selected by adding a '/n' to indicate
the n-th patch set should be downloaded instead of the default of
patch set 1.
Signed-off-by: Shawn O. Pearce <sop@google.com>
This way users are well aware of which account we used when the
uploads are complete, so they can be certain to sign into the web
application with that user identity.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Hosted domain account (such as "@google.com" itself) don't work on the
Google App Engine service unless the user specifically creates their
own Google Account (https://www.google.com/accounts/NewAccount) with
the same email address.
When both such accounts exist we must *only* use the Google Account in
our auth request, as that is all Google App Engine will honor when we
send it the session cookie.
However, Google has internal servers that may also be running Gerrit
based applications. In those case we must use the hosted auth login
for @google.com user accounts, as the internal servers honor only the
hosted account and not the public Google Account database.
In the future we may need to add other domains to the "HOSTED" list
if other Gerrit instances are setup on hosted domains and locked to
only those domain's user accounts, similar to how a server that is
internal to Google would be setup. Since this is currently not a
likely occurrence I'm not worrying about making it configurable at
this juncture.
Signed-off-by: Shawn O. Pearce <sop@google.com>
Many Linux distributions are including python2.5 by default, as
it is the latest stable release of the language. Using python2.4
(and asking users to specifically install it) is just cruel and
unusual punishment.
Signed-off-by: Shawn O. Pearce <sop@google.com>
If the reflog for the upstream branch has only 1 entry in it, as
the branch has been updated only once, we can get back the 0{40}
object id from `git rev-parse upstream@{1}`, in which case we should
consider it to be the same as if upstream@{1} is not defined.
Signed-off-by: Shawn O. Pearce <sop@google.com>
