tools/git-repo.git/tests, branch v2.48

sync: Always use WORKER_BATCH_SIZE

2024-10-07T18:44:19+00:00

With 551285fa35ccd0836513e9cf64ee8d3372e5e3f4, the comment about number of workers no longer stands - dict is shared among multiprocesses and real time information is available. Using 2.7k projects as the baseline, using chunk size of 4 takes close to 5 minutes. A chunk size of 32 takes this down to 40s - a reduction of rougly 8 times which matches the increase. R=gavinmak@google.com Bug: b/371638995 Change-Id: Ida5fd8f7abc44b3b82c02aa0f7f7ae01dff5eb07 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/438523 Commit-Queue: Josip Sokcevic Tested-by: Josip Sokcevic Reviewed-by: Gavin Mak

color: fix have_fg not re assign to true

2024-09-12T16:15:06+00:00

In method _parse the value of this variable 'have_fg ' is always False, Maybe reassign it to True is lost. I guess the author’s original intention was: if set some value in gitconfig file(for ex: text = black red ul), the first is bg color, the second is fg color, and the last one is attr. Change-Id: I372698fe625db4c1fdaa94ea7f193a80a850ecb9 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/425997 Reviewed-by: Mike Frysinger Tested-by: Bright Ma Commit-Queue: Josip Sokcevic

logging: Fix log formatting with colored output

2024-07-02T06:24:31+00:00

The log message is already formatted before being passed to the colorer. To avoid the exception "TypeError: not enough arguments for format string", we should use the `nofmt_colorer` instead. This bug occurs only when the formatted string still contains '%' character. The following snippet can reproduce the bug: ``` from repo_logging import RepoLogger RepoLogger(__name__).error("%s", "100% failed") ``` Change-Id: I4e3977b3d21aec4e0deb95fc1c6dd1e59272d695 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/432017 Tested-by: Shik Chen Commit-Queue: Shik Chen Reviewed-by: Mike Frysinger

sync: Fix sorting for nested projects

2024-03-08T17:58:24+00:00

The current logic to create checkout layers doesn't work in all cases. For example, let's assume there are three projects: "foo", "foo/bar" and "foo-bar". Sorting lexicographical order is incorrect as foo-bar would be placed between foo and foo/bar, breaking layering logic. Instead, we split filepaths based using path delimiter (always /) and then use lexicographical sort. BUG=b:325119758 TEST=./run_tests, manual sync on chromiumos repository Change-Id: I76924c3cc6ba2bb860d7a3e48406a6bba8f58c10 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/412338 Tested-by: Josip Sokcevic Commit-Queue: Josip Sokcevic Reviewed-by: George Engelbrecht

upload: Add support for setting patchset description

2024-03-04T18:50:24+00:00

Bug: 308467447 Change-Id: I7abcbc98131b826120fc9ab85d5b889f90db4b0a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/355968 Tested-by: Sergiy Belozorov Reviewed-by: Mike Frysinger Commit-Queue: Sergiy Belozorov

sync: Introduce git checkout levels

2024-02-27T17:28:33+00:00

If a repo manifest is updated so that project B is placed within a project A, and if project A had content in new B's location in the old checkout, then repo sync could break depending on checkout order, since B can't be checked out before A. This change introduces checkout levels which enforces right sequence of checkouts while still allowing for parallel checkout. In an example above, A will always be checked out first before B. BUG=b:325119758 TEST=./run_tests, manual sync on ChromeOS repository Change-Id: Ib3b5e4d2639ca56620a1e4c6bf76d7b1ab805250 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/410421 Tested-by: Josip Sokcevic Reviewed-by: Greg Edelston Commit-Queue: Josip Sokcevic Reviewed-by: Gavin Mak

tests: setup user identity for tests

2023-12-20T19:04:57+00:00

After a6413f5d a GitCommandError is raised. Since there were no user identity were set up, it fails: - ReviewableBranchTests from test_project.py - ResolveRepoRev and CheckRepoRev from test_wrapper.py Test: ./run_tests Change-Id: Id7f5772afe22c77fc4c8f8f0b8be1b627ed42187 Signed-off-by: Vitalii Dmitriev Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/398658 Reviewed-by: Mike Frysinger Tested-by: Vitalii Dmitriev Commit-Queue: Vitalii Dmitriev

manifest_xml: fix url normalization for inits and remotes

2023-12-20T07:38:49+00:00

Before the change, repo normalizes the urls with a following format only: git@github.com:foo/bar It doesn't cover the following case: Results to: error: Cannot fetch somerepo from ssh://git@github.com/org/git@github.com:org/somerepo Current change fixes it by normalizing this format: git@github.com:foo Test: ./run_tests tests/test_manifest_xml.py Change-Id: I1ad0f5df0d52c0b7229ba4c9a4db4eecb5c1a003 Signed-off-by: Vitalii Dmitriev Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/398337 Commit-Queue: Vitalii Dmitriev Tested-by: Vitalii Dmitriev Reviewed-by: Mike Frysinger

manifest_xml: do not allow / before : in scp-like syntax

2023-12-19T18:00:44+00:00

Since git doesn't treat these as ssh:// URIs, we shouldn't either. Bug: https://g-issues.gerritcodereview.com/issues/40010331 Change-Id: I001f49be30395187cac447d09cb5a6c29e95768b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/398517 Tested-by: Mike Frysinger Reviewed-by: Jason Chang Commit-Queue: Mike Frysinger

sync: Fix partial sync false positive

2023-11-30T22:36:41+00:00

In the case of a project being removed from the manifest, and in the path in which the project used to exist, and symlink is place to another project repo will start to warn about partial syncs when a partial sync did not occur. Repro steps: 1) Create a manifest with two projects. Project a -> a/ and project b -> b/ 2) Run `repo sync` 3) Remove project b from the manifest. 4) Use `link` in the manifest to link all of Project a to b/ Bug: 314161804 Change-Id: I4a4ac4f70a7038bc7e0c4e0e51ae9fc942411a34 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/395640 Reviewed-by: Gavin Mak Tested-by: Matt Schulte Commit-Queue: Gavin Mak