tools/git-repo.git/docs, 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: don't run git ls-remote before fetchcmd on unpinned refs

2026-10-09T21:09:37+00:00

When a project's revision is an unpinned branch or tag and superprojects are not used (so self.revisionId is unset), _CustomFetch previously ran git ls-remote against the Git remote before invoking repo.fetchcmd just to pre-populate REPO_TREV. This added a per-project network round-trip before fetchcmd and forced branch resolution against the Git remote rather than letting fetchcmd resolve REPO_RREV from its own server (just as standard git fetch does in _RemoteFetch). Only populate REPO_TREV before fetchcmd when the target commit SHA is already known (via self.revisionId from superproject or a SHA-pinned revisionExpr). When REPO_RREV is an unpinned branch or tag, leave REPO_TREV empty, let fetchcmd resolve REPO_RREV and update the local tracking ref and FETCH_HEAD, and verify afterward that the tracking ref and FETCH_HEAD resolve to the same valid commit in the object store. Bug: 543101585 Change-Id: I482bf4c022d0e669e5620d4517581ac193983da0 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/640423 Reviewed-by: Brian Gan Commit-Queue: Gavin Mak Tested-by: Gavin Mak

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: 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

hooks: add --fix option to auto-apply hook fixes

2026-08-27T10:28:58+00:00

Pass the --fix flag as a keyword argument "fix" to the hook main function. This allows hooks (such as git-repohooks) to decouple automated fix application from the -y/--yes flag so that -y can answer yes to upload confirmation prompts without triggering file mutations. Companion change in git-repohooks: https://gerrit-review.googlesource.com/c/git-repohooks/+/621761 Bug: 546510319 Test: python3 -m pytest tests/test_hooks.py Change-Id: If0288d4791fc0a2aba6e88854e3aa81b0923b664 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/619281 Commit-Queue: Rahul Yadav Tested-by: Rahul Yadav Reviewed-by: Gavin Mak

hooks: pass yes flag when available

2026-07-20T14:56:03+00:00

Pass the -y flag as a keyword argument "yes" to the hook main function. This allows upload hooks (such as auto-fixers) to automatically apply fixes when the -y flag is passed, rather than prompting the user. Bug: 498893733 Change-Id: I12096029aa3af471ba9175314d749deb0ebd1007 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/605261 Commit-Queue: Rahul Yadav Reviewed-by: Mike Frysinger Tested-by: Rahul Yadav