tools/git-repo.git/subcmds/init.py, branch v1.13.11

Fix inverted logic around [gitc-]init and -c

2020-02-07T20:54:52+00:00

Instead of not using '-c' for '--current-branch' when using gitc, we were only using '-c' when using gitc, so we still had the conflict with the gitc option, and other users still couldn't use '-c'. Test: repo init -u https://android.googlesource.com/platform/manifest; repo init -c Test: repo gitc-init -u ... -b ... -c testing Change-Id: I71e4950a49c281418249f0783c6a2ea34f0d3e2b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253795 Reviewed-by: Mike Frysinger Tested-by: Dan Willemsen (cherry picked from commit 93293ca47f3a898b30eecf21e7b4e1038780c867)

init: handle -c conflicts with gitc-init

2020-02-05T18:04:11+00:00

We keep getting requests for init to support -c. This conflicts with gitc-init which allocates -c for its own use. Lets make this dynamic so we keep it with "init" but omit it for "gitc-init". Bug: https://crbug.com/gerrit/10200 Change-Id: Ibf69c2bbeff638e28e63cb08926fea0c622258db (cherry picked from commit 66098f707a1a3f352aac4c4bb2c4f88da070ca2a) Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253392 Tested-by: Mike Frysinger Reviewed-by: Mike Frysinger

init: Add '-c' as an alias to '--current-branch'

2020-01-24T14:46:58+00:00

This makes it consistent with the short option for current-branch in repo sync. Change-Id: I2848e87f45a66ef8d829576d0c0c4c0f7a8636a0 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/241700 Tested-by: Diogo Ferreira Reviewed-by: David Pursehouse Reviewed-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

Add support for partial clone.

2019-07-16T00:23:16+00:00

A new option, --partial-clone is added to 'repo init' which tells repo to utilize git's partial clone functionality, which reduces disk and bandwidth usage when downloading by omitting blob downloads initially. Different from restricting clone-depth, the user will have full access to change history, etc., as the objects are downloaded on demand. Change-Id: I60326744875eac16521a007bd7d5481112a98749 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/229532 Reviewed-by: Mike Frysinger Tested-by: Xin Li

use print() instead of sys.stdout.write()

2019-07-11T06:26:40+00:00

We're relying on sys.stdout.write() to flush its buffer which isn't guaranteed, and is not the case in Python 3. Change to use print() everywhere to be standard, and utilize the end= keyword to get the EOL semantics we need. We can't use print's flush= keyword as that's only in Python 3. Leave behind a TODO to clean it up when we can drop Python 2. Bug: https://crbug.com/gerrit/10418 Change-Id: I562128c7f1e6d154f4a6ecdf33a70fa2811dc2af Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/230392 Tested-by: Mike Frysinger Reviewed-by: David Pursehouse

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

Honor --depth during repo init

2019-05-21T16:47:21+00:00

If a user is asking for a shallow clone of the repos, they probably expect a shallow clone of the manifest repo too. For very large manifest repos, this can be a huge space and time savings. For one real-world repo, a 'repo init --no-tags --current-branch' used 350MB of disk space and took 7 minutes. Adding --depth 1 and this change reduced it to 10MB and 2.5 minutes. Change-Id: I6fa662e174e623ede8861efc862ce26d65d4958d

init: Remove -c short option for --current-branch

2018-12-20T19:55:02+00:00

This option conflicts with the gitc-init -c short option. Bug: https://crbug.com/gerrit/10200 Change-Id: I06f37564429ca0bd4c0bbea6066daae4f663c838

init: --dissociate option to copy objects borrowed with --reference

2018-10-19T18:51:23+00:00

"repo init --reference" has two purposes: to decrease bandwidth used at clone time, and to decrease disk usage afterward, by using the reference repositories as an alternate store of objects even after the clone. The downside is that it makes the borrowing repositories dependent on the reference repositories, so it is easy to end up with missing objects by mistake after a cleanup operation like "git gc". To prevent that, v2.3.0-rc0~30^2 (clone: --dissociate option to mark that reference is only temporary, 2014-10-14), "git clone" gained a --dissociate option that makes --reference reuse objects from the reference repository at clone time but copy them over instead of using the reference as an alternate. This is more straightforward to use than plain --reference, at the cost of higher disk usage. Introduce a --dissociate to "repo init" that brings the same benefits to repo. The option is simply passed on to "git clone". Change-Id: Ib50a549eb71e0a2b3e234aea57537923962a80d4