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

sync: Use 'git rebase' during 'repo sync --rebase'

2025-10-15T15:32:00+00:00

'repo sync --rebase' should do a rebase if it encounters local commits during a 'repo sync'. This was broken by https://gerrit-review.git.corp.google.com/c/git-repo/+/437421, which caused this to execute the '_doff' hook (which stands for 'do fast forward'), which is implemented using 'git merge --no-stat'. This caused *multiple* actual editor windows to pop up (*) during 'repo sync --rebase', asking the user to enter a commit message for the merge. In this CL I explicitly make that code path do a 'git rebase'. (*) and if you use a terminal editor like 'vim', this means you have 2+ concurrent vim windows rendered in the same terminal, while 'repo sync' keeps on printing other output lines, again in the same terminal. The result is .... not pretty to say the least :( Bug: b:434565811 Test: Used it myself for over a week. Change-Id: I0bf3ff181f15b9d5b2e3f85f7f84e302139fdab7 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/518602 Reviewed-by: Mike Frysinger Tested-by: Jeroen Dhollander Commit-Queue: Jeroen Dhollander

Fix submodule initialization in interleaved sync mode

2025-10-14T19:07:04+00:00

With the introduction of interleaved sync mode, the submodule activation logic broke because the 'has_submodules' attribute was no longer being populated when needed. With this change, each submodule is initialized when it enters the Sync_LocalHalf stage, whereas previously all submodules were initialized at once when the parent repository entered the Sync_LocalHalf stage. The init is now retried if it fails, as submodules may concurrently modify the parent’s git config, potentially causing contention when attempting to obtain a lock on it. This change makes the submodule activation logic more robust and less prone to breakage. Bug: 444366154 Change-Id: I25eca4ea2a6868219045cfa088988eb01ded47d2 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/509041 Reviewed-by: Gavin Mak Tested-by: Kaushik Lingarkar Reviewed-by: Nasser Grainawi Commit-Queue: Kaushik Lingarkar Reviewed-by: Scott Lee

Follow up "Fix shallow clones when upstream attribute is present"

2025-09-22T19:40:22+00:00

This reverts commit 38d2fe11b9df521727fcca23c9dac086ce8378d3. Reason for revert: The issue described in I00acd4c61 remains unresolved. The previous fix incorrectly accessed use_superproject from the Project class, though it was only defined in ManifestProject. This change uses it from the manifest attr available in the Project class. Bug: b/427093249 Change-Id: Ife6d46cd85840f2989f60c2ca4d5a7dcf5d7477a Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/508821 Reviewed-by: Xin Li Reviewed-by: Krzysztof Wesolowski Commit-Queue: Kaushik Lingarkar Reviewed-by: Gavin Mak Tested-by: Kaushik Lingarkar

Revert "Fix shallow clones when upstream attribute is present"

2025-08-14T23:35:26+00:00

This reverts commit d9cc0a15265299b6dcfc1d65f192fd14cfb17b02. Reason for revert: AttributeError: 'Project' object has no attribute 'use_superproject' Bug: b/427093249 Change-Id: I57b285ab21f58b040e68ec14b85425f43f0abcca Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/498641 Reviewed-by: Mike Frysinger Tested-by: Gavin Mak Commit-Queue: Gavin Mak

sync: Record and propagate errors from deferred actions

2025-08-14T06:17:56+00:00

Failures in deferred sync actions were not recorded because `_Later.Run` discarded the `GitError` exception. Record the specific error using `syncbuf.fail()` and propagate it for proper error aggregation and reporting. Bug: 438178765 Change-Id: Iad59e389f9677bd6b8d873ee1ea2aa6ce44c86fa Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/498141 Tested-by: Gavin Mak Reviewed-by: Scott Lee

Fix shallow clones when upstream attribute is present

2025-08-05T15:28:37+00:00

The _CheckForImmutableRevision method was modified in commit 0e776a58 to include upstream branch validation for superproject scenarios. However, this change inadvertently broke shallow clones when both clone-depth and upstream attributes are specified in regular (non-superproject) manifests. Issue: When upstream is present, _CheckForImmutableRevision performs two additional checks: 1. git rev-list on the upstream reference 2. git merge-base --is-ancestor between revision and upstream In shallow clones, the upstream branch history may not be available locally, causing these checks to fail. This triggers the retry mechanism that removes depth limitations, effectively converting shallow clones to full clones, resulting in excessive disk usage. Fix: Make upstream validation conditional on superproject usage. This preserves the original superproject fix while restoring the method's original behavior for regular scenarios - checking only if the immutable revision (SHA1/tag) exists locally. Note: The SetRevisionId method from the same commit 0e776a58 is left unchanged as it only stores upstream information (no git operations), which is beneficial for preserving branch context for commands like 'repo start' without causing fetch-related issues. The fix ensures that manifests with both clone-depth and upstream work correctly in non-superproject scenarios, maintaining shallow clone efficiency and reducing disk usage. Bug: b/427093249 Change-Id: I00acd4c61b179cd2abf796c2fecb7a2f38016a18 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/493883 Tested-by: Krzysztof Wesolowski Commit-Queue: Krzysztof Wesolowski Reviewed-by: Mike Frysinger Reviewed-by: Kamaljeet Maini Reviewed-by: Xin Li

project: fallback to reading HEAD when rev-parse fails

2025-08-04T19:17:44+00:00

git rev-parse fails on invalid HEAD, e.g. after incomplete sync, causing NoManifestException. Fall back to v2.56's direct file reading when rev-parse fails. Bug: 435045466 Change-Id: Ia14560335110c00d80408b2a93595a84446f8a57 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/495181 Commit-Queue: Gavin Mak Reviewed-by: Scott Lee Tested-by: Gavin Mak

project: Fix GetHead to handle detached HEADs

2025-07-25T21:30:07+00:00

The switch to git rev-parse caused GetHead() to return the literal string 'HEAD' when in a detached state. This broke repo prune, which expects a commit SHA. Bug: 434077990 Change-Id: I80b7d5965749096b59e854f61e913aa74c857b99 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/494401 Reviewed-by: Scott Lee Commit-Queue: Gavin Mak Tested-by: Gavin Mak

project: Use git rev-parse to read HEAD

2025-07-21T21:50:46+00:00

Don't directly read `.git/HEAD`, git already has a command for this. Bug: 432200791 Change-Id: Iba030650224143eb07c44da1fa56341d9deb4288 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/492941 Reviewed-by: Scott Lee Commit-Queue: Gavin Mak Tested-by: Gavin Mak

project: Use plumbing commands to manage HEAD

2025-07-17T22:41:59+00:00

Don't directly manipulate `.git/HEAD` since it bypasses Git's internal state management. Bug: 432200791 Change-Id: I1c9264bcf107d34574a82b60a22ea2c83792951b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/491841 Commit-Queue: Gavin Mak Reviewed-by: Scott Lee Tested-by: Gavin Mak