tools/git-repo.git/subcmds/start.py, branch v2.13.5

abandon/start: add --jobs support

2021-02-27T19:45:14+00:00

Use multiprocessing to run in parallel. When operating on multiple projects, this can greatly speed things up. Across 1000 repos, it goes from ~30sec to ~3sec with the default -j8. Change-Id: I0dc62d704c022dd02cac0bd67fe79224f4e34095 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/297484 Tested-by: Mike Frysinger Reviewed-by: Chris Mcdonald

strip python2-only coding:utf-8 & print_function settings

2021-01-06T18:53:05+00:00

We're committed to Python 3 at this point, so clean up boilerplate. Bug: https://crbug.com/gerrit/10418 Change-Id: Ib1719ba2eb65c53b94881a1a1bf203ddfcaaafed Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/292382 Reviewed-by: Chris Mcdonald Tested-by: Mike Frysinger

Fix blank line issues reported by flake8

2020-02-12T06:36:40+00:00

- 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 Tested-by: David Pursehouse

Fix indentation issues reported by flake8

2020-02-12T06:36:22+00:00

- E121 continuation line under-indented for hanging indent - E122 continuation line missing indentation or outdented - E125 continuation line with same indent as next logical line - E126 continuation line over-indented for hanging indent - E127 continuation line over-indented for visual indent - E128 continuation line under-indented for visual indent - E129 visually indented line with same indent as next logical line - E131 continuation line unaligned for hanging indent Fixed automatically with autopep8: git ls-files | grep py$ | xargs autopep8 --in-place \ --select E121,E122,E125,E126,E127,E128,E129,E131 Change-Id: Ifd95fb8e6a1a4d6e9de187b5787d64a6326dd249 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254605 Reviewed-by: Mike Frysinger Tested-by: David Pursehouse

Fix various whitespace issues reported by pyflakes

2020-02-12T06:00:16+00:00

- E201 whitespace after '[' - E202 whitespace before '}' - E221 multiple spaces before operator - E222 multiple spaces after operator - E225 missing whitespace around operator - E226 missing whitespace around arithmetic operator - E231 missing whitespace after ',' - E261 at least two spaces before inline comment - E271 multiple spaces after keyword Fixed automatically with autopep8: git ls-files | grep py$ | xargs autopep8 --in-place \ --select E201,E202,E221,E222,E225,E226,E231,E261,E271 Change-Id: I367113eb8c847eb460532c7c2f8643f33040308c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254601 Reviewed-by: Mike Frysinger Tested-by: David Pursehouse

Add repo start option to create the branch based off HEAD

2019-09-04T04:34:50+00:00

This makes it way easier to recover from forgetting to run repo start before committing: just run `repo start -b new-branch`, instead of all that tedious mucking around with reflogs. Change-Id: I56d49dce5d027e28fbba0507ac10cd763ccfc36d Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/232712 Reviewed-by: Mike Frysinger Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

split out cli validation from execution

2019-08-28T03:54:11+00:00

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 Tested-by: Mike Frysinger

set default file encoding to utf-8

2019-06-13T14:30:52+00:00

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

When starting a branch, do not use a tag or change value for branch.merge

2017-08-25T00:10:29+00:00

When starting a branch, branch.merge is set to project revision unless the revision is a SHA1. In that case, branch.merge is set to dest_branch if defined or manifest default revision otherwise. This special handling allows repo upload to work when the project revision is a SHA1. Extend the special handling to also happen when the project revision is a tag value or a change value so that repo upload will work in those case as well. Change-Id: Iff81ece40e770cd02535e80dcb023564d42dcf47

Consider local project to be default for 'repo start'

2016-09-14T04:17:45+00:00

The requirement to explicitly specify the local project when starting a new repo branch is somewhat counter intuitive. This patch uses the current directory's git tree as the default project. Tested by running 'repo start ' observed that the result is the same as if running 'repo start .' Change-Id: If106caa801b4cd5ba70dbe8354a227d59f100aa3