tools/git-repo.git/command.py, branch v1.12.28

gitc: Improve help visibility

2015-09-01T19:23:56+00:00

This improves the visiblity of gitc-init if we can get the gitc config, and hides it otherwise. Change-Id: I82830b0b07c311e8c74397ba79eb4c361f8b6fb5

GITC: Add repo start support.

2015-08-28T17:53:05+00:00

Add repo start support for GITC checkouts. If the user is in the GITC FS view, they can now run repo start to check out the sources and create a new working branch. When "repo start" is called on a GITC project, the revision tag is set to an empty string and saved in a new tag: old-revision. This tells the GITC filesystem to display the local copy of the sources when being viewed. The local copy is created by pulling the project sources and the new branch is created based off the original project revision. Updated main.py to setup each command's gitc_manifest when appropriate. Updated repo sync's logic to sync opened projects and updating the GITC manifest file for the rest. Change-Id: I7e4809d1c4fc43c69b26f2f1bebe45aab0cae628

Support filtering by group on forall and list subcmd

2015-07-30T17:59:35+00:00

Enable operating against groups of repositories. As it stands, it isn't compatible with `-r/--regex`. `repo forall -g groupname -c pwd` will run `pwd` for all projects in groupname. `repo forall -g thisgroup,-butnotthisone -c pwd` will run `pwd` for all projects in `thisgroup` but not `butnotthisone`. `repo list -g groupname -n` will list all the names of repos in `groupname`. Change-Id: Ia75c50ce52541d1c8cea2874b20a4db2e0e54960

repo: Support multiple branches for the same project.

2013-10-14T22:34:32+00:00

It is often useful to be able to include the same project more than once, but with different branches and placed in different paths in the workspace. Add this feature. This CL adds the concept of an object directory. The object directory stores objects that can be shared amongst several working trees. For newly synced repositories, we set up the git repo now to share its objects with an object repo. Each worktree for a given repo shares objects, but has an independent set of references and branches. This ensures that repo only has to update the objects once; however the references for each worktree are updated separately. Storing the references separately is needed to ensure that commits to a branch on one worktree will not change the HEAD commits of the others. One nice side effect of sharing objects between different worktrees is that you can easily cherry-pick changes between the two worktrees without needing to fetch them. Bug: Issue 141 Change-Id: I5e2f4e1a7abb56f9d3f310fa6fd0c17019330ecd

Optimise regex pattern compilation in FindProjects

2013-04-30T02:12:01+00:00

Make a list of compiled patterns once, and then iterate over that per project, instead of compiling the patterns again on every project. Change-Id: I91ec430d3060ec76d5e6b61facf6b13e343c90a7

Add regex support for subcommand forall

2013-04-29T10:49:26+00:00

Filter the project list based on regex or wildcard matching of strings, then we can handle subset of all projects. Change-Id: Ib6c23aec79e7d981f7b6a5eb0ae93c44effec467 Signed-off-by: Zhiguang Li

Some fixes for supporting python3

2013-04-18T16:05:49+00:00

* Fix imports. * Use python3 syntax. * Wrap map() calls with list(). * Use list() only wherever needed. (Thanks Conley!) * Fix dictionary iteration methods (s/iteritems/items/). * Make use of sorted() in appropriate places * Use iterators directly in the loop. * Don't use .keys() wherever it isn't needed. * Use sys.maxsize instead of sys.maxint TODO: * Make repo work fully with python3. :) Some of this was done by the '2to3' tool [1], by applying the needed fixes in a way that doesn't break compatibility with python2. Links: [1]: http://docs.python.org/2/library/2to3.html Change-Id: Ibdf3bf9a530d716db905733cb9bfef83a48820f7 Signed-off-by: Chirayu Desai

Special handling for manifest group "default"

2013-04-03T22:27:45+00:00

Change Details: * Make "default" a special manifest group that matches any project that does not have the special project group "notdefault" * Use "default" instead of "all,-notdefault" when user does not specify manifest group * Expand -g option help to include example usage of manifest groups Change Benefits: * Allow a more intuitive and expressive manifest groups specification: * "default" instead of "all,-notdefault" * "default,foo" instead of "all,-notdefault,foo" * "default,-foo" instead of "all,-notdefault,-foo" * "foo,-default" which has no equivalent * Default manifest groups behavior can be restored by the command 'repo init -g default'. This is significantly more intuitive than the current equivalent command 'repo init -g all,-notdefault'. Change-Id: I6d0673791d64a650110a917c248bcebb23b279d3

Represent git-submodule as nested projects, take 2

2012-11-19T18:45:21+00:00

(Previous submission of this change broke Android buildbot due to incorrect regular expression for parsing git-config output. During investigation, we also found that Android, which pulls Chromium, has a workaround for Chromium's submodules; its manifest includes Chromium's submodules. This new change, in addition to fixing the regex, also take this type of workarounds into consideration; it adds a new attribute that makes repo not fetch submodules unless submodules have a project element defined in the manifest, or this attribute is overridden by a parent project element or by the default element.) We need a representation of git-submodule in repo; otherwise repo will not sync submodules, and leave workspace in a broken state. Of course this will not be a problem if all projects are owned by the owner of the manifest file, who may simply choose not to use git-submodule in all projects. However, this is not possible in practice because manifest file owner is unlikely to own all upstream projects. As git submodules are simply git repositories, it is natural to treat them as plain repo projects that live inside a repo project. That is, we could use recursively declared projects to denote the is-submodule relation of git repositories. The behavior of repo remains the same to projects that do not have a sub-project within. As for parent projects, repo fetches them and their sub-projects as normal projects, and then checks out subprojects at the commit specified in parent's commit object. The sub-project is fetched at a path relative to parent project's working directory; so the path specified in manifest file should match that of .gitmodules file. If a submodule is not registered in repo manifest, repo will derive its properties from itself and its parent project, which might not always be correct. In such cases, the subproject is called a derived subproject. To a user, a sub-project is merely a git-submodule; so all tips of working with a git-submodule apply here, too. For example, you should not run `repo sync` in a parent repository if its submodule is dirty. Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef

Allow command options to be set from environment variables

2012-11-17T03:40:42+00:00

Extend the Command base class to allow options to be set from values in environment variables, if the user has not given the option on the command line and the environment variable is set. Derived classes of Command can override the implementation of the method _GetEnvironmentOptions to configure which of its options may be set from environment variables. Change-Id: I7c780bcf9644d6567893d9930984c054bce7351e