| commit | d9cc0a15265299b6dcfc1d65f192fd14cfb17b02 | [log] [tgz] |
|---|---|---|
| author | Krzysztof Wesolowski <krzysztof.wesolowski@volvocars.com> | Wed Jul 23 14:40:43 2025 +0200 |
| committer | LUCI <gerrit-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Aug 05 08:28:37 2025 -0700 |
| tree | 449d848155bde877400770981f2bce05c0528ecf | |
| parent | 8c3585f367a7d09095a22565a44fa3b47f5b690c [diff] |
Fix shallow clones when upstream attribute is present 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 <krzysztof.wesolowski@volvocars.com> Commit-Queue: Krzysztof Wesolowski <krzysztof.wesolowski@volvocars.com> Reviewed-by: Mike Frysinger <vapier@google.com> Reviewed-by: Kamaljeet Maini <kamaljeet@google.com> Reviewed-by: Xin Li <delphij@google.com>
Repo is a tool built on top of Git. Repo helps manage many Git repositories, does the uploads to revision control systems, and automates parts of the development workflow. Repo is not meant to replace Git, only to make it easier to work with Git. The repo command is an executable Python script that you can put anywhere in your path.
Please use the repo-discuss mailing list or issue tracker for questions.
You can file a new bug report under the “repo” component.
Please do not e-mail individual developers for support. They do not have the bandwidth for it, and often times questions have already been asked on repo-discuss or bugs posted to the issue tracker. So please search those sites first.
Many distros include repo, so you might be able to install from there.
# Debian/Ubuntu. $ sudo apt-get install repo # Gentoo. $ sudo emerge dev-vcs/repo
You can install it manually as well as it's a single script.
$ mkdir -p ~/.bin $ PATH="${HOME}/.bin:${PATH}" $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo $ chmod a+rx ~/.bin/repo