Currently the upstream tag is not used by dgit, but it is used by
git-deborig or origtargz if the usere asks to make an orig tarball.
With tag2upload, the tag is typically present on the builder.

In neither case, does this tag end up in a formally archived location
on Debian infrastructure.  (It typicaly *is* on salsa.)

Ideally the tag would end up on dgit-repos.  There is a problem,
though: the git tag namespace is global (and there is no standardised
name for upstream tags).  So dgit-repos cannot (and doesn't) allow
arbitrary tags to be pushed.

We need to define a git representation for upstream tags which isn't
"put them under refs/tags/<upstream-tag-name>".  Maybe a new subtree
under refs/.

Should it be indexed by the Debian package version, to allow different
revisions of the "same upstream version" to be based on different git
tags?  That's an anomaly which is current permitted (I think, by
accident) in the Debian archive and therefore by the current system.

Ian.

Ian Jackson writes ("Bug#1106073: dgit should convey upstream git tags to dgit-repos"):

I thought of another question.

For an upload which reuses existing origs, we typically don't
regenerate those origs nor check them against any git information
(except as part of quilt fixup).  In particular, we don't check them
against any git tag(s).

We should only archive an upstream git tag if we know that it
corresponds to the package.  With tag2upload, that could be done by
archivng the tag iff we used it with git-deborig.

When using dgit on the uploader's system, dgit already looks at the
archive to tell whether the orig needs to be included in the .changes.
It could archive the tag under the same circumstances.  But it doesn't
know what "the tag" is - and there may not even *be* one.

The interactions with pristine-tar are also interesting.  Presumably
we'd want to archive all the pristine-tar data?  See #1106071.

Ian.

Hello,

This is indeed quite tricky.  I think it's probably useful for
dgit-repos to be doing this as part of Debian's mission to preserve
upstream source code in a way that's easily accessible, if we can
resolve the many edge cases relating to what the archive allows.