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

sync: Provide a CLI command to opt in/out of smartsync for a user.

2026-10-19T19:20:06+00:00

Add a boolean `sync.smartsync` setting in the per-user repo config (~/.repoconfig/config): * true: smart sync by default, as if -s were passed. * false: never smart sync by default, even if the manifest enables it. * unset: follow the manifest default, as before. Add docs/repoconfig.md as the user facing documentation for ~/.repoconfig/config and its settings, and point smart-sync.md and the `repo sync` help at it. Bug: 569927750 Test: ./run_tests Change-Id: Ideb4119fcb5e90f8bb35c493d9e4f8bec7878b77 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/643264 Reviewed-by: Gavin Mak Commit-Queue: Insaf Latypov Tested-by: Insaf Latypov

sync: Add GetApprovedManifestV2 with named request options

2026-10-14T10:30:36+00:00

Smart sync calls GetApprovedManifest(branch[, target]) over XML-RPC, which only supports positional arguments. Adding new request options that way does not scale. Add a GetApprovedManifestV2 method that takes a single struct of named options and returns a struct: request: {branch, target?, best_effort?} response: {success, manifest_xml?, error_message?} Servers must ignore unknown options, so new options (e.g. criteria for selecting a good build) can be added without another method. The first new option is `best_effort`. repo sets it when smart sync was enabled implicitly by the manifest's sync-smartsync="true" default rather than by -s. The server may decline a best_effort request (e.g. for rollout or cohort gating) by returning success=false. The client still owns the fallback policy: declined implicit requests fall back to a regular sync, while explicit -s requests fail as before. If the server does not implement GetApprovedManifestV2, repo falls back to the legacy GetApprovedManifest call. Bug: 545137090 Test: ./run_tests Change-Id: I9297b728df26516012cb93dffc91d39c1fb0458f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/636623 Reviewed-by: Mike Frysinger Commit-Queue: Rahul Yadav Tested-by: Rahul Yadav

sync: keep smart sync override with -l

2026-10-12T09:14:30+00:00

Splitting a sync into `repo sync -n` followed by `repo sync -l` should end up in the same state as a single `repo sync`. With smart sync it does not always: -n fetches the revisions pinned by the smart sync manifest and saves it as smart_sync_override.xml, but the following -l deletes that override and checks out ToT instead, unless the manifest sets sync-smartsync="true". So `repo sync -s -n` + `repo sync -l` lands on ToT, while `repo sync -s` lands on the pinned revisions. Without an explicit -s or -t, -l does not contact the manifest server, so it cannot choose new pins itself; the only consistent choice is to keep the override the previous -n left behind. Do that regardless of the manifest default. Syncs that choose a manifest themselves still replace or remove the override as before: any sync without -l, and -l combined with -s, -t, -m, --superproject-revision or --no-smart-sync. Smart sync stays non-sticky for regular syncs, and `repo sync -l --no-smart-sync` still discards the override to check out ToT. Bug: 569927750 Change-Id: Id06ff88e9f3183fae32e993e86630fc3e8de71a1 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/640965 Commit-Queue: Rahul Yadav Tested-by: Rahul Yadav Reviewed-by: Gavin Mak

sync: keep --superproject-revision across manifest reloads

2026-10-09T19:56:07+00:00

When --superproject-revision moves `.repo/manifests`, the manifest is reloaded, discarding the pinned superproject. _UpdateProjectsRevisionId then read gitlinks from the superproject's default branch instead, pinning failed, and projects synced unpinned. Apply the revision in _ConfigureSuperproject so it is re-applied after every reload. Verified with https://paste.googleplex.com/5889974172516352 Bug: 571245807 Change-Id: I4d782d229b128c0f15081d11b722d8901709458c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/641743 Reviewed-by: Gavin Mak Tested-by: Brian Gan Commit-Queue: Brian Gan

sync: Support SYNC_BRANCH to override the smart sync branch

2026-10-09T14:00:47+00:00

`repo sync -s` always sends the manifest branch to the manifest server as the `branch` argument of GetApprovedManifest. Some servers map one manifest branch to several server-side (CI) branches, and the only way to pick among them was indirectly through the target. Honor a SYNC_BRANCH environment variable, mirroring SYNC_TARGET: if set and non-empty, send it instead of the manifest branch. An empty value is treated as unset. -t/--smart-tag is unaffected. Bug: 568962967 Test: ./run_tests Change-Id: I26700e8997c21487f83011258100fd91a5c87508 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/639123 Commit-Queue: Rahul Yadav Reviewed-by: Gavin Mak Tested-by: Rahul Yadav

sync: don't let --nmu affect smart sync

2026-10-09T14:00:22+00:00

--no-manifest-update has always meant "use the existing manifest checkout as-is": it skips updating .repo/manifests and nothing else. Smart sync pins do not come from that checkout but from the manifest server, and an explicit `-s --nmu` already works that way. The manifest-driven default smart sync (sync-smartsync="true") instead treated --nmu like -l: it disabled the implicit smart sync and kept an existing smart_sync_override.xml. So on such manifests `repo sync --nmu` fetched and checked out the previous pins (or ToT if there were none) instead of doing what `repo sync` does minus the manifest checkout update. Make --nmu orthogonal to smart sync again: it no longer disables the default smart sync, and it no longer keeps the override. Both have to change together; otherwise a failed implicit smart sync under --nmu would fall back to ToT while leaving the override on disk. Only -l, which skips fetching, keeps the override. Bug: 569927750 Change-Id: I33730363df485d72cd86ae99bf5eb8399b58e81a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/641264 Reviewed-by: Brian Gan Commit-Queue: Rahul Yadav Reviewed-by: Gavin Mak Tested-by: Rahul Yadav

sync: Support manifest-driven default smart sync

2026-10-01T10:13:33+00:00

Add support for enabling smart sync by default via the sync-smartsync="true" attribute on the manifest element. When sync-smartsync is set to true in the manifest defaults: - Plain `repo sync` triggers Smart Sync automatically. - If that implicit Smart Sync fails (manifest server unreachable, or the returned manifest cannot be parsed), repo silently falls back to a regular ToT sync. The reason is logged with --verbose. - `--no-smart-sync` CLI flag overrides the manifest default and syncs to ToT. - Passing explicit `-s` / `--smart-sync` forces Smart Sync as before, and its failures are still fatal. - `-t`, `--smart-tag`, `-m`, `--manifest-name`, and `--superproject-revision` disable the default smart sync. - `-l` / `--local-only` and `--no-manifest-update` skip the manifest server and reuse the existing smart_sync_override.xml, if any. Update docs, completion, regenerate man pages, and add tests for XML parsing, serialization, CLI option resolution, and the fallback and reuse paths. Bug: 545137090 Change-Id: If75569c58dd525d170e9801e70ccbf02206a52f2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/617641 Tested-by: Rahul Yadav Commit-Queue: Rahul Yadav Reviewed-by: Gavin Mak

sync: record superproject sync analysis state again

2026-09-28T22:34:54+00:00

Since the multi-manifest change (bdcba7d), _UpdateProjectsRevisionId rebinds its superproject_logging_data parameter to a new local dict. The caller keeps its own empty dict and passes it to UpdateSyncAnalysisState, so repo.syncstate.superproject.* is never written to the manifest config or logged to trace2. Drop the rebinding so the caller's dict is populated. Also record superproject, haslocalmanifests and hassuperprojecttag when no manifest declares a superproject. Before bdcba7d these keys were logged on every sync. SyncAnalysisState does not remove old keys, so without this a checkout that moves to a manifest without a superproject keeps reporting the values from its last superproject sync. Bug: 565957530 Test: ./run_tests Change-Id: I8796e3a34b9cf4786383d25ecc3ebf0c5409caa3 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634843 Reviewed-by: Gavin Mak Commit-Queue: Ram Peri Tested-by: Ram Peri

sync: keep local sync state paths relative to repo root

2026-09-26T08:17:45+00:00

`LocalSyncState` uses `Project.relpath` to identify projects, but that path is relative to each project's own manifest. Projects in different manifests can have the same relpath, so their fetch and checkout timestamps overwrite each other. This can make a later partial sync look like a full sync. Pruning has a related problem. It treats the stored paths as relative to the current manifest's topdir, so when sync starts from the outermost manifest it can look for submanifest projects in the wrong place and remove valid state. Use `Project.RelPath(local=False)` to identify projects in local sync state and check stored paths from the repo root when pruning. Add tests for same-relpath projects, partial-sync detection, and pruning when sync starts from either the outermost manifest or a submanifest. Change-Id: I24485c315f1277a14913443674245cedd20820fe Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/632421 Reviewed-by: Gavin Mak Reviewed-by: Mike Frysinger Tested-by: Victor Pushkarev Commit-Queue: Victor Pushkarev

Revert "sync: Recommend using --no-use-superproject if sync fails."

2026-09-24T20:53:54+00:00

This reverts commit f907ced0fead284b733872d9d5fd950996e52e9e. Original change: https://gerrit-review.googlesource.com/c/git-repo/+/305622 Reason for revert: the hint was added when a superproject failure made repo sync exit with an error. Since 8db30d6 the failure is non-fatal and sync falls back to fetching normally, and these failures are often transient (e.g. on 2026-09-23 a manifest change added external/slackhq/compose-lints before the superproject had a commit for it, until the change was reverted ~2h later). Following the hint means users keep passing --no-use-superproject and bypass the superproject even after the failure is gone. The revert does not apply cleanly after the black reformat, so the conflict was resolved by restoring the original message text. Bug: 565845573 Change-Id: I5efadedd4d3d0002df50493fa29554ba9626fe82 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634804 Commit-Queue: Ram Peri Reviewed-by: Sam Saccone Tested-by: Ram Peri