Mirror of gerrit.googlesource.com/git-repo https://git.enea.com/cgit/tools/git-repo.git/atom?h=v2.30 2022-11-03T23:01:16+00:00 2022-11-03T23:01:16+00:00 LaMont Jones lamontjones@google.com 2022-11-02T22:01:29+00:00 urn:sha1:fa8d939c8f6a3d25d9a203f28b16a71d891dcc1c If this is a project that is not using object sharing (there is only one copy of the remote project) then clear preciousObjects. To override this for a project, run: git config --replace-all repo.preservePreciousObjects true Change-Id: If3ea061c631c5ecd44ead84f68576012e2c7405c Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/350235 Reviewed-by: Jonathan Nieder <jrn@google.com> Tested-by: LaMont Jones <lamontjones@google.com> 2022-04-14T22:24:04+00:00 LaMont Jones lamontjones@google.com 2022-04-07T21:57:06+00:00 urn:sha1:a46047a822ad13738af9b17a524a0bd483b98033 We need to iterate over multiple manifests, and generally use the outer_client.manifest for multi-manifest support. This refactors the use of self.manifest into a chosen manifest. Change-Id: I992f21d610c929675e99555ece9c38df4b635839 Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/334699 Tested-by: LaMont Jones <lamontjones@google.com> Reviewed-by: Mike Frysinger <vapier@google.com> 2022-04-08T21:06:37+00:00 Daniel Andersson daniel.r.andersson@volvocars.com 2022-04-01T10:55:38+00:00 urn:sha1:d52ca421d52c75837d1614ec54549569f354b7ec The documentation states that a `sync-c` attribute in the manifest file can set a default for whether only the current branch should be fetched or all branches. This seems to have been broken for some time. Commit 7356114 introduced the `--no-current-branch` CLI option and relied on getting `None` via `optparse` if neither `--current-branch` nor `--no-current-branch` was set to distinguish it from a boolean value. If `None` was received, it would read the value from the manifest option `sync-c`. The parsing went through the utility function `_GetCurrentBranchOnly` which returned `True` if `--current-branch` had been given on the command-line, or fell back on the "superproject" setting, which would either return `True` or `None`. This would incorrectly make `repo` fall back to the manifest setting even if the user had given `--no-current-branch` if no superproject was requested -- the manifest became "too powerful": Command-line Using superproject → `current_branch_only` ------------ ------------------ ----------------------- No From manifest Yes True --current-branch No True --current-branch Yes True --no-current-branch No From manifest ← wrong --no-current-branch Yes True In commit 0cb6e92 the superproject configuration value reading changed from something that could return `None` to something that always returned a boolean. If it returned `False`, this would then incorrectly make `repo` ignore the manifest option even if neither `--current-branch` nor `--no-current-branch` had been given. The manifest default became useless: Command-line Using superproject → `current_branch_only` ------------ ------------------ ----------------------- No False ← wrong Yes True --current-branch No True --current-branch Yes True --no-current-branch No False --no-current-branch Yes True By swapping the order in which the command-line option target and the superproject setting is evaluated, things should work as documented: Command-line Using superproject → `current_branch_only` ------------ ------------------ ----------------------- No From manifest Yes True --current-branch No True --current-branch Yes True --no-current-branch No False --no-current-branch Yes True Change-Id: I933c232d2fbecc6b9bdc364ebac181798bce9175 Tested-by: Daniel Andersson <daniel.r.andersson@volvocars.com> Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/334270 Reviewed-by: Mike Frysinger <vapier@google.com>