summaryrefslogtreecommitdiffstats
path: root/command.py
Commit message (Collapse)AuthorAgeFilesLines
* command: add a `repo help` tip to --help outputMike Frysinger2020-02-191-1/+2
| | | | | | | | | | | For people used to running `repo xxx --help`, they might not realize that there are detailed man pages behind `repo help xxx`. Add a note to all --help commands to improve discoverability. Change-Id: I84af58aa0514cc7ead185f6c2534a8f88e09a236 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/255853 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* Fix blank line issues reported by flake8David Pursehouse2020-02-121-0/+2
| | | | | | | | | | | | | | | | | | | | - E301 expected 1 blank line - E302 expected 2 blank lines - E303 too many blank lines - E305 expected 2 blank lines after class or function definition - E306 expected 1 blank line before a nested definition Fixed automatically with autopep8: git ls-files | grep py$ | xargs autopep8 --in-place \ --select E301,E302,E303,E305,E306 Manually fix issues in project.py caused by misuse of block comments. Change-Id: Iee840fcaff48aae504ddac9c3e76d2acd484f6a9 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254599 Reviewed-by: Mike Frysinger <vapier@google.com> Tested-by: David Pursehouse <dpursehouse@collab.net>
* command: Add parentheses on wrapped conditionDavid Pursehouse2020-02-121-3/+3
| | | | | | | | | | | Surround the condition with parentheses rather than using backslashes. This prevents confusion about indentation when running flake8/autoflake8. Change-Id: I01775b96f817ee616f545b55369a4864fa1d6712 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254603 Reviewed-by: Mike Frysinger <vapier@google.com> Tested-by: David Pursehouse <dpursehouse@collab.net>
* command: filter projects by active manifest groupsv1.13.7Mike Frysinger2019-10-081-2/+5
| | | | | | | | | | | | | | | | | | | `repo forall <proj>` will look up all <proj> in the manifest for all manifest groups regardless of which are active. If <proj> is checked out to different locations depending on the group, this ultimately fails as we're unable to locate all of them. Simple fix is to only include projects that match the manifest groups that we already passed down & initialized to the active set, and that we already use when getting the default project list. Bug: https://crbug.com/gerrit/11677 Bug: https://crbug.com/1011226 Change-Id: I975f10f9a9e5a1cad7d87344123f8003732dab27 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/239652 Tested-by: Mike Frysinger <vapier@google.com> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: David Pursehouse <dpursehouse@collab.net>
* split out cli validation from executionv1.13.5Mike Frysinger2019-08-281-0/+10
| | | | | | | | | | | | | | | | | | | A common pattern in our subcommands is to verify the arguments & options before executing things. For some subcommands, that check stage is quite long which makes the execution function even bigger. Lets split that logic out of the execute phase so it's easier to manage these. This is most noticeable in the sync subcommand whose Execute func is quite large, and the option checking makes up ~15% of it. The manifest command's Execute can be simplified significantly as the optparse configuration always sets output_file to a string. Change-Id: I7097847ff040e831345e63de6b467ee17609990e Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/234834 Reviewed-by: David Pursehouse <dpursehouse@collab.net> Tested-by: Mike Frysinger <vapier@google.com>
* set default file encoding to utf-8Mike Frysinger2019-06-131-0/+1
| | | | | | | | There's no reason to support any other encoding in these files. This only affects the files themselves and not streams they open. Bug: https://crbug.com/gerrit/10418 Change-Id: I053cb40cd3666ce5c8a0689b9dd938f24ca765bf
* Remove unused pylint suppressionsDavid Pursehouse2018-07-241-7/+0
| | | | | | | | | | | pylint is not used since bb5b1a0. The pyflakes cleanup mentioned in that commit has not been done, but given that this project is no longer being actively developed I don't think it's worth spending time doing it. Leaving the pylint suppressions causes confusion because it leads people to think that we are still using pylint. Change-Id: If7d9f280a0f408c780f15915ffdb80579ae21f69
* sync: Add support to dump a JSON event log of all sync events.David Riley2017-05-291-0/+2
| | | | Change-Id: Id4852968ac1b2bf0093007cf2e5ca951ddab8b3b
* repo: Repo does not always handle '.' parameter correctlyMark E. Hamilton2016-04-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The repo script allows a manifest to specify a '.' as the path the top-level directory, which co-locates the .git and .repo directories, and places files from the git repository at the top-level: <project name="proj_name" path="." /> <project name="sierra.other.git" path="other" /> Most commands work correctly with this setup. Some commands, however, fail to find the project. For instance, 'repo sync' works, and 'repo sync .' works in a sub-project ('other' in this case) but 'repo sync .' in the top-level directory fails with the error: error: project . not found There are two reasons for this: 1. The self.worktree attribute of the Project object is not normalized, so with a '.' for path its value would be '/my/project/root/.'. This is fine when used as a path, since it's the same path as '/my/project/root', but when used in a string comparison it fails. This commit applies os.path.normpath() to that value before storing it. 2. The _GetProjectByPath method in command.py was not checking the path against manifest.topdir, so even once it was normalized the project was not found. This commit adds a check against manifest.topdir if the loop drops out without finding a project. Change-Id: Ic84d053f1bbb5a357cad566805d5a326ae8246d2
* Add --inverse-regex option to forall subcommandTakeshi Kanemoto2016-04-051-2/+8
| | | | | | | | | | Make it possible to exclude projects using regex/wildcard. The syntax is similar to that of the -r option, e.g.: repo forall -i ^platform/ ^device/ -c 'echo $REPO_PROJECT' Change-Id: Id250de5665152228c044c79337d3ac15b5696484
* command.py: Cleaned up pylint/pep8 violationsMark E. Hamilton2016-03-021-12/+16
| | | | | | | | | | | I noticed when running pylint (as the SUBMITTING_PATCHES file directs) that there were a few violations reported. This makes it difficult to see violations I might have introduced. This commit corrects all pylint violations in the command.py script. This script now has a pylint score of 10.0. Change-Id: Ibb35fa9af0e0b9b40e02ae043682b3af23286748
* Add GitcClientCommand class for GITC-specific commandsDan Willemsen2015-09-291-1/+6
| | | | | | | These won't show up as common commands in the help text unless in a GITC client, and will refuse to execute. Change-Id: Iffe82adcc9d6ddde9cb4b204f83ff018042bdab0
* gitc: Improve help visibilityv1.12.28Dan Willemsen2015-09-011-0/+5
| | | | | | | 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.Simran Basi2015-08-281-8/+11
| | | | | | | | | | | | | | | | | | | | | 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 subcmdGraham Christensen2015-07-301-2/+3
| | | | | | | | | | | | | | | | 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.David James2013-10-141-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | 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 FindProjectsDavid Pursehouse2013-04-301-2/+2
| | | | | | | 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 forallZhiguang Li2013-04-291-0/+11
| | | | | | | | 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 <muzili@gmail.com>
* Some fixes for supporting python3Chirayu Desai2013-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | * 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 <cdesai@cyanogenmod.org>
* Special handling for manifest group "default"David Holmer2013-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | 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 2Che-Liang Chiou2012-11-191-25/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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 variablesDavid Pursehouse2012-11-171-0/+40
| | | | | | | | | | | | 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
* Even more coding style cleanupDavid Pursehouse2012-10-301-1/+1
| | | | | | | | | | | Fixing some more pylint warnings: W1401: Anomalous backslash in string W0623: Redefining name 'name' from outer scope W0702: No exception type(s) specified E0102: name: function already defined line n Change-Id: I5afcdb4771ce210390a79981937806e30900a93c
* Revert "Represent git-submodule as nested projects"v1.11.1Shawn O. Pearce2012-10-261-48/+24
| | | | | | | | | | | This reverts commit 69998b0c6ff724bf620480140ccce648fec7d6a9. Broke Android's non-gitmodule use case. Conflicts: project.py subcmds/sync.py Change-Id: I68ceeb63d8ee3b939f85a64736bdc81dfa352aed
* Add pylint configuration and instructionsDavid Pursehouse2012-10-241-2/+2
| | | | | | | | | | pylint configuration file (.pylintrc) is added, and submission instructions are updated to include pylint usage steps. Deprecated pylint suppression (`disable-msg`) is updated in a few modules to make it work properly with the latest version (0.26). Change-Id: I4ec2ef318e23557a374ecdbf40fe12645766830c
* Represent git-submodule as nested projectsChe-Liang Chiou2012-10-231-24/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: I541e9e2ac1a70304272dbe09724572aa1004eb5c
* More coding style cleanupDavid Pursehouse2012-10-221-0/+7
| | | | | | | | | | | | | | | | Fixing more issues found with pylint. Some that were supposed to have been fixed in the previous sweep (Ie0db839e) but were missed: C0321: More than one statement on a single line W0622: Redefining built-in 'name' And some more: W0631: Using possibly undefined loop variable 'name' W0223: Method 'name' is abstract in class 'name' but is not overridden W0231: __init__ method from base class 'name' is not called Change-Id: Ie119183708609d6279e973057a385fde864230c3
* Coding style cleanupDavid Pursehouse2012-10-091-4/+4
| | | | | | | | | | | | | | | Fix the following issues reported by pylint: C0321: More than one statement on a single line W0622: Redefining built-in 'name' W0612: Unused variable 'name' W0613: Unused argument 'name' W0102: Dangerous default value 'value' as argument W0105: String statement has no effect Also fixed a few cases of inconsistent indentation. Change-Id: Ie0db839e7c57d576cff12d8c055fe87030d00744
* Allow projects to be specified as notdefaultConley Owens2012-09-051-1/+1
| | | | | | | | | | | | Instead of every group being in the group "default", every project is now in the group "all". A group that should not be downloaded by default may be added to the group "notdefault". This allows all group names to be positive (instead of removing groups directly in the manifest with -default) and offers a clear way of selecting every project (--groups all). Change-Id: I99cd70309adb1f8460db3bbc6eff46bdcd22256f
* Treat groups= as defaultColin Cross2012-04-231-1/+1
| | | | | | | | | Previous incarnations of groups support left "groups=" in the repo .config, which is now treated as "delete all the projects". Treat empty groups configuration the same as no groups configuration. Change-Id: I57dab8dac55bdbf4cc181e2748cd2e4e510764f5
* Add a --platform flagConley Owens2012-04-231-1/+2
| | | | | | | | | | Projects may optionally specify their platform (eg, groups="platform-linux" in the manifest). By default, repo will automatically detect the platform. However, users may specify --platform=[auto|all|linux|darwin]. Change-Id: Ie678851fb2fec5b0938aede01f16c53138a16537
* Refine groups functionalityConley Owens2012-04-231-3/+4
| | | | | | | | | | | | | | | Every project is in group "default". "-default" does not remove it from this project. All group names specified in the manifest are positive names as opposed to a mix of negative and positive. Specified groups are resolved in order. If init is supplied with --groups="group1,-group2", the following describes the project selection when syncing: * all projects in "group1" will be added, and * all projects in "group2" will be removed. Change-Id: I1df3dcdb64bbd4cd80d675f9b2d3becbf721f661
* Add manifest groupsv1.8.2Colin Cross2012-04-131-1/+12
| | | | | | | | | | | | | | | | | Allows specifying a list of groups with a -g argument to repo init. The groups act on a group= attribute specified on projects in the manifest. All projects are implicitly labelled with "default" unless they are explicitly labelled "-default". Prefixing a group with "-" removes matching projects from the list of projects to sync. If any non-inverted manifest groups are specified, the default label is ignored. Change-Id: I3a0dd7a93a8a1756205de1d03eee8c00906af0e5 Reviewed-on: https://gerrit-review.googlesource.com/34570 Reviewed-by: Shawn Pearce <sop@google.com> Tested-by: Shawn Pearce <sop@google.com>
* Make path references OS independentAnthony Newnam2011-01-091-2/+4
| | | | | | | | | Change-Id: I5573995adfd52fd54bddc62d1d1ea78fb1328130 (cherry picked from commit b0f9a02394779c1c9422a9649412c9ac5fb0f12f) Conflicts: command.py
* Add -p to `repo forall` to improve output formattingShawn O. Pearce2009-04-181-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to read log output from many projects at once it can be difficult to make sense of which messages came from where. For many professional developers it is common to want to view the last week's worth of your work, so you can write a weekly summary of your activity for your status report. This is easier with the new -p option: repo forall -pc git log --reverse --since=1.week.ago --author=sop produces a report of all commits written by me in the last week, formatted in a paged output display, with headers inserted in front of each project's output. Where this can be even more useful is with git log's pickaxe, e.g. now we can use: repo forall -pc git log -Sbar v1.0..v1.1 to locate all additions or removals of the symbol 'bar' since v1.0, up to and including v1.1. Before displaying the matching commits in a project, a project header is shown, giving the user some context information for the matching results. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Don't permit users to run repo status in a mirror clientShawn O. Pearce2009-03-031-0/+5
| | | | | | | | | | | | | | | | 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>
* Initial Contributionv1.0The Android Open Source Project2008-10-211-0/+116