Hello,
I recently got https://blueprints.launchpad.net/linaro-infrastructure-misc/+spec/rebasing-t... to verify current state of affairs with repo handling of SHA revisions for commits which have underlying tags. The blueprints contains full details, let me in this report mail cover just we most important bits.
1. We have been having problem with repositories used in Android releases being rebased later for a long time.
2. Trying to resolve that, we established policy that any revision used in a release must be tagged, to make sure that exact revision stays across rebases.
3. That didn't really work well with "repo" tool from ~1.5yr ago, because it did not fetch tags by default, so rebased revisions were still unreachable.
4. We did our patching to repo and submitted it to Google, which then was lost in great kernel.org demise of 2011, and later they rejected it telling they'd do it in different way.
5. Fast forward to modern time, I verified that repo v1.12.2 works as expected wrt to fetching commits by SHA revs, if they have underlying tag, so we're covered for policy of p.2.
6. However, few repos were found to still be rebased without tagging release revisions. To address that, following options are proposed:
a) Disallow to use SHA revs in release manifests. Granted, that would make more effort to do a release then just get pinned manifest of some build, but may improve release process by prompting to ensure that releases are made from Android Team managed mirrors of repositories, and that all such repositories are tagged in consistent manner (which how upstream does it).
b) Verify that each SHA has underlying tag. A bit more challenging technically (i.e. possibility for unexpected behavior), and misses the chance to move release process to a new level, but should be still doable.
Note that both choices preserve ability to rebase repositories, which is considered an important developers' right ;-).