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

Fixing forall subcommand for Py3

2020-02-11T04:31:45+00:00

Execution of 'repo forall -p -c' doesn't work with Py3 and ends up with an error: Got an error, terminating the pool: TypeError: can only concatenate str (not "bytes") to str That's fixed by using the decode() method. Change-Id: Ice01aaa1822dde8d957b5bf096021dd5a2b7dd51 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/253659 Reviewed-by: Mike Frysinger Reviewed-by: David Pursehouse Tested-by: Jiri Tyr (cherry picked from commit 83a3227b62c936b346b825b333fc2ca65528ecfd)

remove spurious +x bits

2020-02-11T04:31:03+00:00

These files are not directly executable, so drop the +x bits. Change-Id: Iaf19a03a497686cc21103e7ddf08073173440dd1 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/254076 Tested-by: Mike Frysinger Reviewed-by: David Pursehouse (cherry picked from commit e7c91889a6ff23931d3fbc25481b276e50ed8229)

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

info: Add the manifest revision

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

After Ib546f5ebbc8a23875fbd14bf166fbe95b7dd244e, repo info now displays the current project revision in the 'Current revision' field. While the output is more consistent, there are use cases for the revision expression as shown in the manifest. This patch re-adds the manifest revision as a new 'Manifest revision' field. Change-Id: I50c1559dcb7ceb69af07352b956d78f85b8f592e Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/240799 Tested-by: Diogo Ferreira Reviewed-by: Mike Frysinger

help: unify command display

2019-12-03T02:31:05+00:00

No functional changes, just unifying duplicate code paths. Change-Id: I6afa797ca1e1eb90abdc0236325003ae070cbfb3 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/247293 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

upload/editor: fix bytes/string confusion

2019-11-16T23:55:30+00:00

The upload module tries to turn the strings into bytes before passing to EditString, but it combines bytes & strings causing an error. The return value might be bytes or string, but the caller only expects a string. Lets simplify this by sticking to strings everywhere and have EditString take care of converting to/from bytes when reading/writing the underlying files. This also avoids possible locale confusion when reading the file by forcing UTF-8 everywhere. Bug: https://crbug.com/gerrit/11929 Change-Id: I07b146170c5e8b5b0500a2c79e4213cd12140a96 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/245621 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger

prune: handle branches that track missing branches

2019-11-16T19:55:02+00:00

Series of steps: * Create a local "b1" branch with `repo start b1` that tracks a remote branch (totally fine) * Manually create a local "b2" branch with `git branch --track b1 b2` that tracks the local "b1" (uh-oh...) * Delete the local "b1" branch manually or via `repo prune` (....) * Try to process the "b2" branch with `repo prune` Since b2 tracks a branch that no longer exists, everything blows up at this point as we try to probe the non-existent ref. Instead, we should flag this as unknown and leave it up to the user to resolve. This probably could come up if a local branch was tracking a remote branch that was deleted from the server, and users ran something like `repo sync --prune` which cleaned up the remote refs. Bug: https://crbug.com/gerrit/11485 Change-Id: I6b6b6041943944b8efa6e2ad0b8b10f13a75a5c2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/236793 Reviewed-by: David Pursehouse Reviewed-by: Kirtika Ruchandani Reviewed-by: Mike Frysinger Tested-by: Mike Frysinger

sync: merge project updates with status bar

2019-11-12T23:33:51+00:00

The current sync output displays "Fetching project" and "Checking out project" messages and progress bar updates independently leading to a lot of spam. Lets merge these periodic outputs with the status bar to get a little bit tighter output in the normal case. This doesn't solve all our problems, but gets us closer. Bug: https://crbug.com/gerrit/11293 Change-Id: Icd627830af4dd934a9355b7ace754b56dc96cfef Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/244934 Reviewed-by: David Pursehouse Tested-by: Mike Frysinger