summaryrefslogtreecommitdiffstats
path: root/project.py
Commit message (Collapse)AuthorAgeFilesLines
...
* sync: Support downloading bundle to initialize repositoryv1.7.7Shawn O. Pearce2011-09-281-11/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add commit-msg hook also for manifest projectVictor Boivie2011-07-201-1/+4
| | | | | | | | | | | | | | | The manifest project has - by design - not a review URL associated with it. It is actually not even a 'project' in repo's sense. This will prevent the commit-msg hook from being added, which is not necessarily wanted as the project is managed in gerrit. This commit will enable the commit-msg hook, which in turn will add the Change-Id-line to every new commit in it. This simplifies replacing patch sets (by git push ... refs/for/...). Change-Id: I42d0f6fd79e6282d9d47074a3819e68d968999a7 Signed-off-by: Victor Boivie <victor.boivie@sonyericsson.com>
* Add a --depth option to repo init.v1.7.5Doug Anderson2011-06-091-0/+7
| | | | Change-Id: Id30fb4a85f4f8a1847420b0b51a86060041eb5bf
* Add branch support to repo uploadMandeep Singh Baines2011-05-261-1/+3
| | | | | | | | | | | | | | | | This commit adds a --br=<branch> option to repo upload. repo currently examines every non-published branch. This is problematic for my workflow. I have many branches in my kernel tree. Many of these branches are based off of upstream remotes (I have many remotes) and will never be uploaded (they'll get sent upstream as a patch). Having repo scan these branches adds to my upload processing time and clutters the branch selection buffer. I've also seen repo get confused when one of my branches is 1000s of commits different from m/master. Change-Id: I68fa18951ea59ba373277b57ffcaf8cddd7e7a40
* Fixed repo checkout error message when git reports errors.Doug Anderson2011-04-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current version of repo checkout, we often get the error: error: no project has branch xyzzy ...even when the actual error was something else. This fixes it to only report the 'no project has branch' when that is actually true. This fix is very similar to one made for 'repo abandon': https://review.source.android.com/#change,22207 The repo checkout error is filed as: <http://crosbug.com/6514> TEST=manual A sample creating a case where 'git checkout' will fail: $ repo start branch1 . $ repo start branch2 . $ touch bogusfile $ git add bogusfile $ git commit -m "create bogus file" [branch2 f8b6b08] create bogus file 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 bogusfile $ echo "More" >> bogusfile $ repo checkout branch1 . error: chromite/: cannot checkout branch1 A sample case showing that we still fail if no project has a branch: $ repo checkout xyzzy . error: no project has branch xyzzy Change-Id: I48a8e258fa7a9c1f2800dafc683787204bbfcc63
* Fixed repo abandon to give better messages.Doug Anderson2011-04-071-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main fix is to give an error message if nothing was actually abandoned. See <http://crosbug.com/6041>. The secondary fix is to list projects where the abandon happened. This could be done in a separate CL or dropped altogether if requested. TEST=manual $ repo abandon dougabc; echo $? Abandon dougabc: 100% (127/127), done. Abandoned in 2 project(s): chromite src/platform/init 0 $ repo abandon dougabc; echo $? Abandon dougabc: 100% (127/127), done. error: no project has branch dougabc 1 $ repo abandon dougabc; echo $? Abandon dougabc: 100% (127/127), done. error: chromite/: cannot abandon dougabc 1 Change-Id: I79520cc3279291acadc1a24ca34a761e9de04ed4
* Add option to check status of projects in parallel.Terence Haddock2011-04-071-4/+12
| | | | Change-Id: I6ac653f88573def8bb3d96031d3570ff966251ad
* Creating rr-cachev1.7.4.1Victor Boivie2011-03-171-0/+5
| | | | | | | | | | | If git-rerere is enabled, it uses the rr-cache directory that repo currently creates a symlink from, but doesn't create the destination directory (inside the project's directory). Git will then complain during merges and rebases. This commit creates the rr-cache directory inside the project. Change-Id: If8b57a04f022fc6ed6a7007d05aa2e876e6611ee
* Support repo-level pre-upload hook and prep for future hooks.v1.7.4Doug Anderson2011-03-111-1/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All repo-level hooks are expected to live in a single project at the top level of that project. The name of the hooks project is provided in the manifest.xml. The manifest also lists which hooks are enabled to make it obvious if a file somehow failed to sync down (or got deleted). Before running any hook, we will prompt the user to make sure that it is OK. A user can deny running the hook, allow once, or allow "forever" (until hooks change). This tries to keep with the git spirit of not automatically running anything on the user's computer that got synced down. Note that individual repo commands can add always options to avoid these prompts as they see fit (see below for the 'upload' options). When hooks are run, they are loaded into the current interpreter (the one running repo) and their main() function is run. This mechanism is used (instead of using subprocess) to make it easier to expand to a richer hook interface in the future. During loading, the interpreter's sys.path is updated to contain the directory containing the hooks so that hooks can be split into multiple files. The upload command has two options that control hook behavior: - no-verify=False, verify=False (DEFAULT): If stdout is a tty, can prompt about running upload hooks if needed. If user denies running hooks, the upload is cancelled. If stdout is not a tty and we would need to prompt about upload hooks, upload is cancelled. - no-verify=False, verify=True: Always run upload hooks with no prompt. - no-verify=True, verify=False: Never run upload hooks, but upload anyway (AKA bypass hooks). - no-verify=True, verify=True: Invalid Sample bit of manifest.xml code for enabling hooks (assumes you have a project named 'hooks' where hooks are stored): <repo-hooks in-project="hooks" enabled-list="pre-upload" /> Sample main() function in pre-upload.py in hooks directory: def main(project_list, **kwargs): print ('These projects will be uploaded: %s' % ', '.join(project_list)) print ('I am being a good boy and ignoring anything in kwargs\n' 'that I don\'t understand.') print 'I fail 50% of the time. How flaky.' if random.random() <= .5: raise Exception('Pre-upload hook failed. Have a nice day.') Change-Id: I5cefa2cd5865c72589263cf8e2f152a43c122f70
* Post-nonexistent-revision crash sidesteppedSkyler Kaufman2011-03-081-2/+2
| | | | | | | | | Fix for the bug that leaves a fractional .git directory after attempting to perform an initial sync to a nonexistent revision. Moved the initialization of the working directory to after the revision ID has already been checked. Now, no project/.git directory gets created at all if the revision ID is bad. Change-Id: I0c9b2a59573410f1d11de7661591bf02e4ce326b
* Renamed 'repo_hooks' function to '_ProjectHooks'.Doug Anderson2011-02-011-7/+18
| | | | | | | | | | | | | | This renaming was done for two reasons: 1. The hooks are actually project-level hooks, not repo-level hooks. Since we are talking about adding repo-level hooks, It keeps things less confusing if we name the existing hooks to be "ProjectHooks" 2. The function is a private function in project.py and so should have capitalization to match. I also added a docstring describing this function. Change-Id: I1d30f5de08e8f9f99f78146e68c76f906782d97e
* Fixed bug identifying 'commit-msg' files.Doug Anderson2011-02-011-1/+1
| | | | | | | | | | | There was a minor typo that would cause repo to (I believe) mistakenly identify any file that contained a substring of the word 'commit-msg' as a commit message hook. For example, the file 'mit' or the file 'msg' would be treated as a commit message hook. I believe that it was intended that repo only recognize files named exactly 'commit-msg'. Change-Id: I93edbddf3da3cf0935641e6efb19b0a8ee6e2308
* Fix mirror clients with no worktreev1.7.3.1Shawn O. Pearce2011-01-101-1/+4
| | | | | | | | Commit "Make path references OS independent" (df14a70c45) broke mirror clients by trying to invoke replace() on None when there is no worktree. Change-Id: Ie0a187058358f7dcdf83119e45cc65409c980f11
* Make path references OS independentAnthony Newnam2011-01-091-2/+2
| | | | | | | | | Change-Id: I5573995adfd52fd54bddc62d1d1ea78fb1328130 (cherry picked from commit b0f9a02394779c1c9422a9649412c9ac5fb0f12f) Conflicts: command.py
* upload: Remove --replace optionFicus Kirkpatrick2010-10-291-6/+0
| | | | | | | It hasn't been necessary for a long time, and its functionality can be accomplished with 'git push'. Change-Id: Ic00d3adbe4cee7be3955117489c69d6e90106559
* sync --quiet: be more quietShawn O. Pearce2010-10-291-6/+11
| | | | | Change-Id: I5e8363c7b32e4546d1236cfc5a32e01c3e5ea8e6 Signed-off-by: Shawn O. Pearce <sop@google.com>
* sync: Enable use of git clone --referenceShawn O. Pearce2010-10-291-7/+94
| | | | | | | | | 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>
* upload -t: Automatically include local branch nameShawn O. Pearce2010-07-151-4/+13
| | | | | | | | | | | If the -t flag is given to upload, the local branch name is automatically sent to Gerrit Code Review as the topic branch name for the change(s). This requires the server to be Gerrit Code Review v2.1.3-53-gd50c94e or later, which isn't widely deployed right now, so the default is opt-out. Change-Id: I034fcacb405b7cb909147152db427fe69dd7bcbf Signed-off-by: Shawn O. Pearce <sop@google.com>
* Warn users before uploading if there are local changesAnthony Newnam2010-07-151-0/+21
| | | | | Change-Id: I231d7b6a3211e9f5ec71a542a0109b0c195d5e40 Signed-off-by: Shawn O. Pearce <sop@google.com>
* sync: Try fetching a tag as a last resort before giving upJulius Gustavsson2010-07-151-3/+18
| | | | | | | | | | | | | | If a tagged commit is not reachable by the fetch refspec configured for the git (usually refs/heads/*) it will not be downloaded by 'git fetch'. The tag can however be downloaded with 'git fetch --tags' or 'git fetch tag <tag>'. This patch fixes the situation when a tag is not found after a 'git fetch'. Repo will issue 'git fetch tag <tag>' before giving up completely. Change-Id: I87796a5e1d51fcf398f346a274b7a069df37599a Signed-off-by: Shawn O. Pearce <sop@google.com>
* Allow files to be copied into new foldersMatthew Buckett2010-05-271-0/+4
| | | | Change-Id: I7f169e32be5a4328bb87ce7c2ff4b6529e925126
* Automatically install Gerrit Code Review's commit-msg hookv1.6.9Shawn O. Pearce2010-03-061-4/+18
| | | | | | | | | | | | | Most users of repo are also using Gerrit Code Review, and will want the commit-msg hook to be automatically installed into their local projects so that Change-Ids are assigned when commits are created, not when they are first uploaded. (cherry picked from commit a949fa5d202f0a1f812d7630f3e5bf0f02ca4e98 but squashed with latest hook script from version 2.1.2) Change-Id: Ie68b2d60ac85d8c2285d2e1e6a4536eb76695547 Signed-off-by: Shawn O. Pearce <sop@google.com>
* Fail sync when encountering "N commits behind."Daniel Sandler2010-03-041-4/+3
| | | | | | | | | | This is almost always something the user needs to address before continuing work, so promoting it to a failure (rather than simply an informational message) seems the right way to go. As a side-effect, repo will now exit with a non-zero status code in this situation, so pipelines of the form `repo sync && make` will fail if there are branches that are stalled due to uploaded but unmerged patches.
* Check that we are not overwriting a local repository when syncing.v1.6.8.11Nico Sallembien2010-01-201-1/+4
| | | | | | | | If a local git repository exists within the same folder as a new project that is added, when the user syncs the repo, the sync will overwrite the local files under the project's .git repository with its own symlinks. Make sure that we do not overwrite 'normal' files in repo and throw an error when that happens.
* sync: Fix split call on malformed email addressesv1.6.8.9Shawn O. Pearce2009-12-301-1/+1
| | | | | | | | | | | | | If an email address in a commit object contains a space, like a few malformed ones on the Linux kernel, we still want to split only on the first space. Unfortunately my brain was too damaged by Perl and originally wrote the split asking for 2 results; in Python split's argument is how many splits to perform. Here we want only 1 split, to break apart the commit identity from the email address on the same line. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Silence 'Current branch %s is up to date' during syncShawn O. Pearce2009-06-031-3/+1
| | | | | | | | We accidentally introduced this message during 1.6.8 by always invoking `git rebase` when there were no new commits from the upstream, but the user had local commits. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Fix unnecessary self in project.pyShawn O. Pearce2009-06-011-1/+1
| | | | Signed-off-by: Shawn O. Pearce <sop@google.com>
* Change project.revision to revisionExpr and revisionIdShawn O. Pearce2009-05-291-91/+89
| | | | | | | | | 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>
* Change DWIMery hack for dealing with rewound remote branchShawn O. Pearce2009-05-291-35/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | The trick of looking at the reflog for the remote tracking branch and only going back one commit works some of the time, but not all of the time. Its sort of relying on the fact that the user didn't use `repo sync -n` or `git fetch` to only update the tracking branches and skip the working directory update. Doing this right requires looking through the history of the SHA-1 source (what the upstream used to be) and finding a spot where the DAG diveraged away suddenly, and consider that to be the rewind point. That's really difficult to do, as we don't have a clear picture of what that old point was. A close approximation is to list all of the commits that are in HEAD, but not the new upstream, and rebase all of those where the committer email address is this user's email address. In most cases, this will effectively rebase only the user's new original work. If the user is the project maintainer and rewound the branch themselves, and they don't want all of the commits they have created to be rebased onto the new upstream, they should handle the rebase on their own, after the sync is complete. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Refactor how projects parse remotes so it can be replacedShawn O. Pearce2009-05-291-12/+13
| | | | | | | | | 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>
* Remove support for the extra <remote> definitions in manifestsShawn O. Pearce2009-05-191-15/+0
| | | | | | | | | These aren't that widely used, and actually make it difficult for users to fully mirror a forest of repositories, and then permit someone else to clone off that forest, rather then the original upstream servers. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Automatically guess Gerrit change number in "repo upload --replace"v1.6.7.4Ficus Kirkpatrick2009-05-051-0/+13
| | | | | This feature only works if you have one commit to replace right now (the common case).
* Perform copy file activity when creating a new work directoryv1.6.7.1Shawn O. Pearce2009-04-211-0/+1
| | | | | | | | | | | | Performance improvements in repo sync caused us to skip out of the initial Sync_LocalHalf without ever running CopyFiles, so we didn't create the top level Makefile in new clients whose manifest request one with a <copyfile> element. Now we run CopyFiles after the initial read-tree that populates the project working directory. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Fix 'repo sync' rebase logic on a published branchv1.6.7Shawn O. Pearce2009-04-211-6/+3
| | | | | | | | | If the current branch is published, but all published commits are merged into the manifest revision, but there is also at least one unpublished commit on the current branch, we should rebase the unpublished commit, rather than creating a merge commit. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Automatically use SSH control master support during syncShawn O. Pearce2009-04-181-1/+9
| | | | | | | | | By creating a background ssh "control master" process which lives for the duration of our sync cycle we can easily cut the time for a no-op sync of 132 projects from 60s to 18s. Bug: REPO-11 Signed-off-by: Shawn O. Pearce <sop@google.com>
* Highlight projects which still have sync failures during 'repo status'Shawn O. Pearce2009-04-181-3/+15
| | | | Signed-off-by: Shawn O. Pearce <sop@google.com>
* Modify 'repo abandon' to be more like 'repo checkout' and 'repo start'Shawn O. Pearce2009-04-181-10/+30
| | | | Signed-off-by: Shawn O. Pearce <sop@google.com>
* Improve checkout performance for the common unmodified caseShawn O. Pearce2009-04-181-11/+32
| | | | | | | | | Most projects will have their branch heads matching in all branches, so switching between them should be just a matter of updating the work tree's HEAD symref. This can be done in pure Python, saving quite a bit of time over forking 'git checkout'. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Add progress meter to 'repo start'Shawn O. Pearce2009-04-181-2/+4
| | | | | | | | | | This is mostly useful if the number of projects to switch is many (e.g. all of Android) and a large number of them are behind the current manifest revision. We wind up needing to run git just to make the working tree match, and that often makes the command take a couple of seconds longer than we'd like. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Make usage of open safer by setting binary mode and closing fdsShawn O. Pearce2009-04-181-4/+6
| | | | Signed-off-by: Shawn O. Pearce <sop@google.com>
* Speed up 'repo start' by removing some forksShawn O. Pearce2009-04-181-22/+60
| | | | | | | | | | Its quite common for most projects to be matching the current manifest revision, as most developers only modify one or two projects at any one time. We can speed up `repo start foo` (that impacts the entire client) by performing most of the branch creation and switch operations in pure Python, and thus avoid 4 forks per project. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Remove unused methods from project.ReviewableBranchShawn O. Pearce2009-04-181-10/+0
| | | | | | | | These used to be used back when we had Gerrit 1.x support and used HTTP based uploads to transmit changes for review. Since we moved entirely to Gerrit 2.x, these are no longer called. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Only fetch repo once-per-day under normal 'repo sync' usageShawn O. Pearce2009-04-181-0/+8
| | | | | | | | | | | Its unlikely that a new version of repo will be delivered in any given day, so we now check only once every 24 hours to see if repo has been updated. This reduces the sync cost, as we no longer need to contact the repo distribution servers every time we do a sync. repo selfupdate can still be used to force a check. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Avoid git fork on the common case of repo not changingShawn O. Pearce2009-04-181-1/+19
| | | | | | | | | Usually repo is upgraded only once a week, if that often. Most of the time we invoke HasChanges on the repo project (or even on the manifest project) the current HEAD will resolve to the same SHA-1 as the remote tracking ref, and there are therefore no changes. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Avoid unnecessary git symbolic-ref calls during repo syncShawn O. Pearce2009-04-171-3/+6
| | | | | | | | If the m/BRANCH ref is already pointing at the value set in the manifest there is no reason to set it again. Leave it alone, thus saving a full fork+exec call. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Improve repo sync performance by avoid git forksShawn O. Pearce2009-04-171-15/+49
| | | | | | | | | | | By resolving the current HEAD and the manifest revision using pure Python, we can in the common case of "no changes" avoid a lot of git operations and directly jump out of the local sync method. This reduces the no-op `repo sync -l` time for Android's 114 projects from more than 6s to under 0.8s. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Implement git ref reading purely in PythonShawn O. Pearce2009-04-171-26/+4
| | | | | | | | | | | | | | | | | Its much faster to read the refs from 114 projects when the reader is pure Python and just doing file IO than forking 114 git commands and parsing their output. The reader caches refs based upon file mtimes. If any single ref file has been modified since the last read, we re-read the entire repository's ref namespace. This simplifies the code as we don't need to worry about shooting down symbolic-refs, but it may cause more IO than is necessary if only one ref gets updated. This change drops `repo branches` in Android from 1.658s to 0.206s. Likewise, `repo sync` improves dramatically as well. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Implement 'git symbolic-ref HEAD' in PythonShawn O. Pearce2009-04-171-8/+11
| | | | | | | | This is invoked once per project in `repo sync`. Taking it out saves about 1/114 of a second, so on a large set of projects like Android it can save up to a full second of sync time. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Remove confusing message from repo sync outputShawn O. Pearce2009-04-171-1/+0
| | | | | | | | Someone pointed out this message isn't always the truth; so we shouldn't print it. The code path is executed when there are published commits, yet our output talks about unpublished ones. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Change repo sync to be more friendly when updating the treev1.6.6Shawn O. Pearce2009-04-161-56/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>