I wrote: > 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.
I decided to use just a single ref and rely on the user having a suitable reflog and object expiry policy. > * The fetch will fetch the destination *branch* into the user's > tracking remote. My implementation does *not* do this. Mostly because figuring out what that would be like would involve parsing refspecs and reimplementing complex git logic. Instead, my implementation prints the remote's URL in some of the error messages in the hope that this is helpful. > 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. ... > * Tag exists locally but *not* remotely (or we didn't fetch) > and contains different tag to what we would generate. I have not yet implemented this part. > * 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. I *have* implemented this part. Ian. -- 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.
