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>
1 file changed
tree: f25b587abc73703c0ef22d344d6a9bc14b18f9f5
  1. .flake8
  2. .gitattributes
  3. .github/
  4. .gitignore
  5. .mailmap
  6. .project
  7. .pydevproject
  8. LICENSE
  9. MANIFEST.in
  10. README.md
  11. SUBMITTING_PATCHES.md
  12. color.py
  13. command.py
  14. completion.bash
  15. docs/
  16. editor.py
  17. error.py
  18. event_log.py
  19. git_command.py
  20. git_config.py
  21. git_refs.py
  22. git_ssh
  23. git_superproject.py
  24. git_trace2_event_log.py
  25. gitc_utils.py
  26. hooks.py
  27. hooks/
  28. main.py
  29. manifest_xml.py
  30. pager.py
  31. platform_utils.py
  32. platform_utils_win32.py
  33. progress.py
  34. project.py
  35. release/
  36. repo
  37. repo_trace.py
  38. requirements.json
  39. run_tests
  40. setup.py
  41. subcmds/
  42. tests/
  43. tox.ini
  44. wrapper.py
README.md

repo

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.

Contact

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.

Install

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