| commit | 347f9ed393b7a44d775ffb436f8bae304d82729f | [log] [tgz] |
|---|---|---|
| author | Mike Frysinger <vapier@google.com> | Mon Mar 15 14:58:52 2021 -0400 |
| committer | Mike Frysinger <vapier@google.com> | Fri Apr 09 03:16:45 2021 +0000 |
| tree | f25b587abc73703c0ef22d344d6a9bc14b18f9f5 | |
| parent | 9a734a3975c1fc45a43466f1a42e3f2ca588bd19 [diff] |
sync: rework selfupdate logic The current logic has a downside in that it doesn't sync to the latest signed version available if the latest commit itself is unsigned. This can come up when using the "main" branch as it is sometimes signed, but often not as it's holding the latest merged commits. When people use the main branch, it's to get early testing on versions tagged but not yet released, and we don't want them to get stuck indefinitely on that old version of repo. For example, this series of events: * "stable" is at v2.12. * "main" is tagged with v2.13. * early testers use --repo-rev main to get v2.13. * new commits are merged to "main". * "main" is tagged with v2.14. * new commits are merged to "main". * devs who had synced in the past to test v2.13 are stuck on v2.13. repo sees "main" is unsigned and so doesn't try to upgrade at all. The only way to get unwedged is to re-run `repo init --repo-rev main`, or to manually sync once with repo verification disabled, or for us to leave "main" signed for a while and hope devs will sync in that window. The new logic is that whenever changes are available, we switch to the latest signed tag. We also replace some of the duplicated verification code in the sync command with the newer wrapper logic. This handles a couple of important scenarios inaddition to above: * rollback (e.g. v2.13.8 -> v2.13.7) * do not trash uncommitted changes (in case of ad-hoc testing) * switch tag histories (e.g. v2.13.8 -> v2.13.8-cr1) Change-Id: I5b45ba1dd26a7c582700ee3711f303dc7538579b Reviewed-on: https://gerrit-review.googlesource.com/c/git-repo/+/300122 Reviewed-by: Jonathan Nieder <jrn@google.com> Reviewed-by: Michael Mortensen <mmortensen@google.com> Tested-by: Mike Frysinger <vapier@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