tools/git-repo.git/docs, branch v2.72

docs: add Repology links for distro package versions

2026-11-02T21:20:14+00:00

The Ubuntu and Debian release wiki pages added in https://gerrit-review.googlesource.com/c/git-repo/+/649983 only list distro release and EOL dates, not which versions of Python, Git, or OpenSSH shipped in each distro release. Add Repology package version links alongside the distro release pages in python-support.md and requirements.json so maintainers can check which versions shipped across historical Ubuntu and Debian releases. Bug: 575551885 Change-Id: Ib256fd9b364074b52d3e15d185af519d8376cb28 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/650868 Reviewed-by: Gavin Mak Tested-by: Brian Gan Commit-Queue: Brian Gan

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