tools/git-repo.git, branch v2.69

git_config: Fix bugs in processing RepoConfig.

2026-10-14T14:49:21+00:00

- Automatically create all the parent directories for `git confing --file ...` - Prevent `RepoConfig` from inheriting caches from `GitConfig`. These two are different files. Bug: 569927750 Test: ./run_tests Change-Id: I9c60cecff75c1fb62be3ff63425d9618c0f56b06 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/643263 Reviewed-by: Mike Frysinger Tested-by: Insaf Latypov Commit-Queue: 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

repo: tolerate a transiently missing stable branch

2026-10-13T20:55:40+00:00

The automated release process deletes the stable branch and then recreates it. A client that fetches during that window can't find it: `repo init` fails to resolve --repo-rev, and the daily self-update in `repo sync` fails with "Cannot fetch repo tool". In the launcher, if --repo-rev doesn't resolve after the initial fetch, wait 10 seconds and refetch once before giving up. `resolve_repo_rev` gains a `report_errors` flag so this first check doesn't print an error that the refetch then fixes. Bump the launcher version to 2.69 so existing users pick this up. For fetches of the repo project itself (sync's self-update and `repo selfupdate`), wait 10 seconds instead of 4 before retrying. The delay is now a `RETRY_SLEEP_INITIAL_SEC` class attribute that `RepoProject` overrides, so other projects keep the 4 second delay. This replaces the unused `retry_sleep_initial_sec` parameter of `_RemoteFetch`. Bug: 566270786 Change-Id: I23cb810258522b5aa9eae9d7013dbb7904ebcad8 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/643265 Tested-by: Brian Gan Commit-Queue: Brian Gan Reviewed-by: Gavin Mak

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: skip clone.bundle when repo.fetchcmd is configured

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

In Sync_NetworkHalf, clone_bundle defaults to True on initial sync when self.objdir does not exist yet, and _ApplyCloneBundle is called before custom_fetch_configured is checked. For remotes with HTTP/HTTPS URLs that serve /clone.bundle, this causes repo sync to download and unpack the full clone.bundle into .git/objects before invoking repo.fetchcmd. Skip _ApplyCloneBundle when custom_fetch_configured is enabled so repo.fetchcmd exclusively handles object fetching. Bug: 543101585 Change-Id: If41a775a75589ad5a23106163f9932e2940b72d2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/641685 Commit-Queue: Gavin Mak Reviewed-by: Brian Gan Tested-by: Gavin Mak

project: peel annotated tags in GetRevisionId with cached refs

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

When all_refs (e.g. self.bare_ref.all in Sync_LocalHalf) is passed to GetRevisionId, looking up a tag ref in all_refs returns the tag object SHA for annotated tags rather than the peeled commit SHA. In Sync_LocalHalf, this causes repo.reprojectcmd to receive a tag SHA in REPO_TREV and DetachHead to fail with 'trying to write non-commit object to branch HEAD', and causes standard checkouts to re-checkout on every subsequent sync because HEAD (the commit SHA) never equals revid (the tag object SHA). Skip the all_refs fast path for refs/tags/* so tags always fall through to bare_git.ResolveCommit, which peels to the underlying commit SHA. Bug: 543101585 Change-Id: Ie4afa3cee9149e2a8438bd8fb4a8026a210848d8 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/641683 Commit-Queue: Gavin Mak Reviewed-by: Brian Gan Tested-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

agents: enable generic multi-perspective code review agent

2026-10-09T20:10:58+00:00

Configure git-repo-code-review-agent with use_default_subagents: true in agents/agent_configs.txtpb so groupagent-grev-review uses the generic gerrit_reviewer multi-perspective review framework. Bug: 555706086 Change-Id: I079681b00e71cb886dc2343692d88b01d58a51ea Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/641904 Reviewed-by: Brian Gan Tested-by: Becky Siegel

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: roll back repo when stable is rewound

2026-10-09T16:49:49+00:00

The documented way to roll back a bad release is to force push an older release to stable, and docs/release-process.md says clients will then automatically downgrade. _PostRepoFetch already supports switching to an older commit, but it only runs when `RepoProject.HasChanges` is true, and that used the `MetaProject` check of whether the remote has commits that HEAD lacks. After a rewind it doesn't, so clients that had already upgraded stayed on the bad release. Make `RepoProject.HasChanges` true whenever the remote revision differs from HEAD, in either direction. `ManifestProject` keeps the forward-only check so local manifest commits are still rebased rather than dropped. Bug: 571204396 Change-Id: I248507f434d2552ce11a9afabe9a6335cb24ddbd Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/640130 Reviewed-by: Gavin Mak Tested-by: Brian Gan Commit-Queue: Brian Gan