In t2u job 991, git-debpush selected a tag `v2.1.13` for upstream.
But that was a bare tag ref - that is, refs/tags/v2.1.13 points
directly to a commit, not a tag object.

This is an unusual thing for a maintainer to do.  Also, if we were to
implement
  #1110269 tag2upload (and dgit?) should deposit upstream tags
we might have to forbid it.

Ian.

Hello,

Huh, how strange.  Yes, it would make sense just to rule out such refs.
If upstream is providing those (if they can even be fetched?) then the
maintainer should use an annotated upstream/vN tag.

Hi Simon,
[...]

I wonder if #1115394 [1] is the source of your initial recollection? The
bug suggests that lightweight (bare ref) upstream tags are unusual and
that when they are present maintainers should synthesise a corresponding
annotated upstream/X tag. I suspect these types of upstream tags are
more prevalent in practice.

I've set replies to the bug for this.

Andrew

[1] https://bugs.debian.org/1115394 "git-debpush should maybe fail a
    check for bare ref upstream tags"

Is this really all that unusual?  It may be undesirable for one reason
or another, but in my world I very frequently see examples of both
lightweight and annotated tags being used to mark releases.

Random example which is not at all special, just the first place I
happened to look, and I found an example on the first try:

   $ git clone https://github.com/PyO3/maturin
   $ git -C maturin cat-file -t v1.11.5
   commit