tools/git-repo.git/subcmds/sync.py, branch v2.68

sync: reuse status HEAD in the bloat scan

2026-09-21T20:39:21+00:00

The shallow-project bloat check already needs dirty state. Request branch metadata in that same porcelain-v2 snapshot and use branch.oid instead of launching a separate rev-parse, with the existing calls retained as a fallback. Bug: 543851900 Bug: 553599402 Change-Id: I3e7068c2e14c025a53adf92bfe8483b876cfda9d Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/632145 Tested-by: Gavin Mak Reviewed-by: Brian Gan Commit-Queue: Gavin Mak

sync: keep generated jobs-checkout help host-independent

2026-09-16T11:51:54+00:00

The default shown for `--jobs-checkout` comes from `DEFAULT_LOCAL_JOBS`, which depends on the host CPU count. As a result, regenerating the sync and smartsync manpages on a different machine can change their output even though repo's behavior has not changed. Use shared CPU-based help formatting for `--jobs` and `--jobs-checkout`. Interactive help still shows the actual default, while generated manpages describe it without including a host-specific value. Runtime job selection is unchanged. Add coverage for both help modes and regenerate the affected manpages. Change-Id: Ia60e6fcc17b6f4618c52a76217c128eddead8848 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/625381 Reviewed-by: Mike Frysinger Commit-Queue: Victor Pushkarev Tested-by: Victor Pushkarev Reviewed-by: Gavin Mak

sync: implement reprojectcmd for the local half

2026-09-15T19:53:01+00:00

Add `repo.reprojectcmd`, the checkout counterpart to `repo.fetchcmd`. When set, `repo sync` runs this command instead of Git to materialize a project's index and worktree at the target tree, while `repo` handles ref updates directly via `git update-ref`. This replaces Git's tree materialization steps: detaching HEAD, fast-forwarding, and hard-resetting. Rebasing is not delegated, and the command is skipped if HEAD is already at the target, if HEAD is ahead of the target during fast-forward, or for MetaProjects. The command runs in a subshell with project environment variables (such as `REPO_TREV`). Before running, `repo` ensures no operation is in progress and no staged changes exist. Worktree collision detection is delegated to the command (preserving benign unstaged/untracked edits). Afterward, `repo` verifies that HEAD was untouched and that the index matches the target tree. Like `repo.fetchcmd`, this requires `repo.uselocalgitdirs`. Nested projects and submodules are unsupported; `repo sync` fails if the manifest contains any while `repo.reprojectcmd` is enabled. Verified end-to-end with repo init using local-gitdirs, repo.fetchcmd, and repo.reprojectcmd ('git -C $REPO_PATH read-tree -m -u $REPO_TREV'): * Verified detached HEAD checkout and correct reflog generation across projects. * Verified benign unstaged edits and untracked files survive checkout. * Verified conflicting untracked files fail with exit 128 without clobbering worktree. * Verified staged changes fail upfront before reprojectcmd is executed. Bug: 513329573 Change-Id: I964d24d22dccffc05a9b991ad69f3a7e93268c01 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/626281 Tested-by: Gavin Mak Reviewed-by: Brian Gan Commit-Queue: Gavin Mak

sync: tell apart same-path submanifest projects

2026-09-02T02:13:52+00:00

Interleaved sync remembers which projects are done and which ones are still pending by Project.relpath, and lists failing projects by it as well. That path is relative to the project's own (sub)manifest though, so once several manifests are synced together two projects can share it, and the sets no longer tell them apart. The damage is done when a project turns up in a later pass, e.g. a submodule that is only derived once its parent has been synced: its path is already recorded as finished, so it is left out of every pass that follows and never synced, while sync still reports success. With an outer manifest holding where a carries a submodule at b, and a submanifest at sub/ holding a fresh `repo sync` checks out sub/a/b but never a/b. Failing projects are reported under the same ambiguous path, and the stall detection merges them too. Use RelPath(local=opt.this_manifest_only) instead, which is unique within the set of projects being synced and is what GetProjects() and the other subcommands already use. Spotted during the review of I30395b8a16a9154f60972e1f408a066af64ba77c. Change-Id: I5fa694b968774667be6060d9722cb57acbd2b579 Signed-off-by: kimhappy Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/622641 Reviewed-by: Gavin Mak Reviewed-by: Brian Gan

sync: skip submodules removed from their parent

2026-08-27T23:22:54+00:00

The submodules to sync are derived from their parent before it is fetched, so one that the parent's new revision no longer holds a gitlink for is still synced. Interleaved sync then fails to check it out, because `git submodule init` no longer knows that path: error: Cannot checkout a/c error: pathspec '.../a/c' did not match any file(s) known to git Report such submodules while the gitlinks are read again, and leave them out of the fetch and of the checkout, so the usual project list update removes them from the working tree. Phased sync already left them out of the checkout, but still fetched them. Nothing is reported as removed while the gitlinks of a parent cannot be read, since a missing gitlink cannot be told apart from a fetch that did not happen. Bug: 550074864 Change-Id: Ia429b35c12758a68e4df73665e5512a201af658a Signed-off-by: kimhappy Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/621681 Reviewed-by: Gavin Mak Reviewed-by: Brian Gan

sync: fetch submodules after their parent repository

2026-08-27T23:22:49+00:00

Phased sync fetches every project at once, so a submodule is fetched at the gitlink that was read before its parent was fetched. With -c that stale revision is already present, the fetch is skipped as an immutable revision, and the checkout then fails on the revision the reloaded manifest resolved: error: Cannot checkout a/b fatal: bad object 5556dad99da5df7e53303c5732aacc8782493e03 Fetch in batches, holding a submodule back until the project holding its gitlink is fetched, and read the gitlinks again between batches. A manifest without submodules keeps its single batch. Bug: 550074864 Change-Id: I04c2eb1ca81ab25b4df2c03c5dc048d2e4ecdcb8 Signed-off-by: kimhappy Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/621663 Reviewed-by: Gavin Mak Reviewed-by: Brian Gan

sync: check out submodules at the parent's new revision

2026-08-27T23:22:43+00:00

Interleaved sync processes projects in hierarchical levels, so a submodule is only handled after the project holding its gitlink has been fetched and checked out. Its revision, however, is still the one read before that parent was fetched, so the submodule is synced to the revision of the previous sync and only catches up on the next one. Read the gitlinks again right before a level is dispatched. The parent is done by then, so its submodules are fetched and checked out at the revision the parent now points at. Sibling submodules are spread over several levels, so the gitlinks read for one level are carried over to the next ones and every project is only read once per pass. Bug: 550074864 Change-Id: I30395b8a16a9154f60972e1f408a066af64ba77c Signed-off-by: kimhappy Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/621662 Reviewed-by: Gavin Mak Reviewed-by: Brian Gan

command: Respect smart sync override declaratively by default

2026-08-04T18:38:03+00:00

Introduce a `RESPECT_SMART_SYNC_OVERRIDE` class attribute to the base `Command` class, defaulting to `True`. This allows subcommands to automatically respect the smart sync override manifest if it exists. The override is applied in `CommonValidateOptions` before any subcommand-specific validation or execution occurs. The `sync` and `init` commands explicitly opt out. This ensures all workspace-aware subcommands consistently align with the active smart sync override manifest. It also fixes a bug in multi-manifest setups where running a command from a submanifest would not apply the override to the outer manifest, causing inconsistency when resolving projects across all manifests. Bug: 279204331 Change-Id: I9426e90a13a77ce6bd94b4a82efda4d485cbe116 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/585081 Reviewed-by: Mike Frysinger Tested-by: Gavin Mak Commit-Queue: Gavin Mak

sync: allow syncing groups with repo sync -g group

2026-07-21T20:42:38+00:00

Similar to how repo init -g can restrict repo syncs to a subset of the manifest globally, allow "repo sync -g" to only sync a subset of projects from the manifest when running that specific sync command. Change-Id: I4929aad109de05c73a7db42bb27fd8d47eea32fc Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/609481 Reviewed-by: Mike Frysinger Commit-Queue: Andrew Chant Reviewed-by: Gavin Mak Tested-by: Andrew Chant

sync: Deprecate fetch-submodules flag names

2026-07-21T07:19:21+00:00

The names for flags --fetch-submodules / --no-fetch-submodules are misleading, since they impact the full sync operation (fetch and checkout), not just the fetching. Introduce new flags --recurse-submodules / --no-recurse-submodules and treat the old ones as deprecated aliases. Change-Id: I78339a3e0496a855c222c1869b27b578507886a7 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/608881 Commit-Queue: Josef Malmstrom Reviewed-by: Gavin Mak Reviewed-by: Mike Frysinger Tested-by: Josef Malmstrom