tools/git-repo.git/project.py, branch v2.70

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

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

init: don't suggest --no-use-superproject on failure

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

When the superproject can't be fetched, repo init warns and tells users to re-run repo init with --no-use-superproject. That choice is saved in the checkout config (repo.superproject), so following it disables the superproject for that checkout until it is re-inited, even though these failures are often transient. Drop the recommendation and keep the rest of the warning. This is the repo init counterpart of reverting https://gerrit-review.googlesource.com/c/git-repo/+/305622 for repo sync (https://gerrit-review.googlesource.com/c/git-repo/+/634804). Bug: 565845573 Change-Id: I91a6e682ef1d1c6dee07bc7969de88a681e1d239 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634784 Tested-by: Ram Peri Reviewed-by: Sam Saccone Reviewed-by: Arif Kasim Commit-Queue: Ram Peri

project: don't plan a stateless prune without a worktree

2026-09-23T20:27:06+00:00

Skip stateless prune planning when a project's worktree directory does not exist, preventing fetch failures on subsequent syncs. Also run _LsRemote() bare so it does not depend on worktree existence. Bug: 565047698 Change-Id: I385cba4e06813d9113ec7ddc963e8499acffaec5 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634426 Tested-by: Gavin Mak Commit-Queue: Gavin Mak Reviewed-by: Brian Gan

sync: skip the bloat check for projects without a worktree

2026-09-23T20:27:01+00:00

Skip shallow clone bloat checks during --network-only syncs and filter out projects whose worktree directory does not exist on disk. Also return None quietly from _GetStatusSnapshot() when a project lacks an existing worktree directory. Bug: 565047698 Change-Id: Ia4c7db36a2bd78bc89e7b72f7a492b901b50efa7 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634425 Commit-Queue: Gavin Mak Reviewed-by: Brian Gan Tested-by: Gavin Mak

project: don't rerun git status after a failed snapshot

2026-09-23T20:26:55+00:00

When a status snapshot fails, fall back directly to _IsDirtyLegacy() instead of IsDirty() to avoid running git status twice. Expose Project.GetDirtyAndHead() so sync bloat checks can inspect worktree state without invoking private Project methods. Bug: 565047698 Change-Id: I6432ed82da88778eec9d151fd5b70bedb1efc62b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634424 Reviewed-by: Brian Gan Commit-Queue: Gavin Mak Tested-by: Gavin Mak

project: avoid unnecessary sync revision enumeration

2026-09-21T20:40:01+00:00

Skip the detached-history walk when its count will not be printed, ask rev-list --count for upstream gain, and cap the published-but-unmerged existence probe at one commit. These preserve the decisions while reducing traversal and output work. Bug: 553599402 Change-Id: I30f769c9aa5269428ece15ffcb45c50993d7c4b8 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/634004 Commit-Queue: Gavin Mak Tested-by: Gavin Mak Reviewed-by: Brian Gan