tools/git-repo.git/docs, branch main

docs: release: update release process to match current practice

2026-10-27T19:29:45+00:00

The documented process has drifted from how releases are actually done: * Releases are now cut weekly by an automated pipeline, so the manual steps are only a fallback, and for rollbacks. * Releases are tested (both updating an existing checkout and a fresh init) before pushing anything. * The tag is pushed & announced first, and only promoted to stable after a day. * Direct pushes to the stable branch are rejected, so it has to be deleted & recreated via the Gerrit REST API instead. Bug: 575551885 Change-Id: Ib36df07811c225558aba1a925b9703f3b2017e6f Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/649984 Reviewed-by: Gavin Mak Tested-by: Brian Gan Commit-Queue: Brian Gan

docs: release: remove stale Project References table

2026-10-27T17:39:40+00:00

The table of git/python/ssh/distro versions hasn't been kept up to date and duplicates information maintained upstream by the distros and projects themselves. Drop it, and point the places that referenced it (python-support.md & requirements.json) at the Ubuntu & Debian release pages instead. Bug: 575551885 Change-Id: Id1cb2225b3852273ca717fc7a443449fb2fd006e Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/649983 Reviewed-by: Gavin Mak Tested-by: Brian Gan Commit-Queue: Brian Gan

config: add subcommand to manage ~/.repoconfig/config

2026-10-22T15:34:46+00:00

Per-user settings such as sync.smartsync live in ~/.repoconfig/config, but reading or changing them required knowing the file location and running `git config --file ~/.repoconfig/config ...`. Add `repo config` as a thin wrapper around RepoConfig.ForUser(), following the subcommand style of modern `git config`: * `repo config get ` prints the value(s), exiting 1 if unset. * `repo config set ` sets it. * `repo config unset ` removes it; a missing key is a no-op. * `repo config list` shows all settings. Values are stored as strings; `--type=bool|int` validates and canonicalizes them on set and get, like `git config --type`. `-z` makes get and list NUL-terminated for scripting. Setting names are validated by `git config` itself when writing. Factor the value parsing out of GitConfig.GetBoolean()/GetInt() into ParseBoolean()/ParseInt() so the command and the readers agree, and accept on/off/1/0 as booleans like git does. Only the per-user file is handled; per-checkout settings in .repo/manifests.git/config are out of scope. Like other subcommands, it runs from inside a repo checkout. Update docs/repoconfig.md to use the new command in its examples and add zsh completion and the man page. Bug: 569927750 Test: ./run_tests Change-Id: I940d0318549fe9d79f6f9173139f0b96a706f1bf Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/645727 Reviewed-by: Mike Frysinger Tested-by: Insaf Latypov Commit-Queue: Insaf Latypov

sync, init: support repo.smartsync config and --head alias

2026-10-21T18:22:58+00:00

Allow users to configure Smart Sync as the default for a checkout: * Add `ManifestProject.smart_sync` backed by `self.config.GetBoolean("repo.smartsync")`. * Add `-s`/`--smart-sync` and `--no-smart-sync`/`--head` to `repo init` to persist `repo.smartsync` in the manifest project config. * Add `--head` as an alias for `--no-smart-sync` in `repo sync` and `repo init`. * Update `Sync._ResolveSmartSyncOption` so `ManifestProject.smart_sync` takes precedence over `` while remaining overridable by per-invocation `repo sync` CLI flags. Bug: 569927750 Test: pytest tests/test_project.py tests/test_subcmds_init.py tests/test_subcmds_sync.py Change-Id: Ib40efc530336efb59a28acfed3d582713e9d67b2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/643303 Reviewed-by: Mike Frysinger Commit-Queue: LaMont Jones Tested-by: LaMont Jones

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