We talked about this some more on irc. AIUI we have decided: * The fetch should try to fetch the tag that would be made by git-debpush, from salsa; if it exists it should end up in the user's refs/tags/.
* The fetch should try to fetch the previous DEP-14 maintainer tag (based on the changelog) but *not* into the user's refs/tags/. This will influence quilt mode selection - eg in case a co-maintainer has changed the quilt mode and our user hasn't pulled so doesn't have that tag. We'll save the successive fetches to refs/dgit/debpush-cache/debian/SUTIE or something, with reflog enabled, so that this private tag fetch is properly memoised. * The fetch will fetch the destination *branch* into the user's tracking remote. * The fetch will *not* attempt to fetch any archive/ tag(s). The reason we care about those is just the "accidentally uploading from dgit view" check; I think we can hope that in that scenario the user has the tag(s) as well as just the branch. * git-debpush --tag-only should operate solely offline so shouldn't do this fetch. * git-debpush --dry-run *will* do the fetch. I've thought about tag tag out-of-course situations: * Tag exists locally but *not* remotely (or we didn't fetch) and contains the same tag as we would generate. Diagnosis: tag push failed. Action: Unconditionally repush the existing tag rather than remaking it. (Doing this makes git-debpush idempotent. and avoids prompting the user for a safe action.) * Tag exists locally but *not* remotely (or we didn't fetch) and contains different tag to what we would generate. Diagnosis: for some reason (maybe previous git-debpush attempt, maybe ad-hoc git-tag, maybe sponsorship) user has a "wrong" DEP-14 tag that they might want to replace. Action: Check failed, `replace-tag`. * Tag exists remotely already: Diagnosis: this version has already been used for a release. Maybe the user is accidentally re-using a version number. Anyway we don't want to change a published tag. Unconditional failure. Recovery: if the problem was just that the tag was wrong somehow (eg wrong quilt mode) the user should bump the version number. When we're comparing the tag text, we consider the tag body, and everything in the git header apart for the date in the tagger line. We don't verify the signature, but a "same tag" must be one that looks signed. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
