Hi!  Recently I've been migrating my workflow from

git-debpush --upstream=upstream/1.2.3

to

git-debpush --upstream=v1.2.3

based on some debian-devel discussions suggesting recording upstream git
tags (with associated commit id) into Debian's dgit view may provide
some additional supply-chain feature.  It isn't clear to me if there is
sufficient consensus to actually recommend this style over the former,
or if there are any disadvantages with this style.  I'm using this style
to gain experience with it.

This has worked well, until I wanted to upload a version of a package
where upstream doesn't tag their releases, and we just track git:

jas@frallan:~/dpkg/golang-github-crawshaw-iox$ LANG=C git-debpush --remote=origin --upstream=c51c3df3079724bad60b626b5114e12cfa6cb859
fatal: ambiguous argument 'refs/tags/c51c3df3079724bad60b626b5114e12cfa6cb859^{}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
jas@frallan:~/dpkg/golang-github-crawshaw-iox$

Indeed git-debpush --upstream is documented to accept only a git tag:

control: tag -1 + wontfix

Hello,

Simon Josefsson [08/Feb 11:09am +01] wrote:

This is impossible because without a tag we can't guarantee that the
commit is actually fetchable.

The recommended thing to do here is create an upstream/foo tag yourself.

Sean Whitton <spwhitton@spwhitton.name> writes:

That works, and gbp does it for me.

I suppose this ought to be a documented limit of the "--upstream=v1.2.3"
workflow style, which I guess this bug report now serve as.

There are two other limits of that style that I've ran into:

1) Packages that repack upstream orig.tar using, e.g., Files-Excluded.

2) Packages whose upstream uses .gitattributes export-subst to modify
source in git compared to release tarballs.

So maybe this workflow is flawed after all, although I do like having
upstream SHA1 git commit ids recorded in the debian tag2upload tag.

/Simon

Hello,

Simon Josefsson [08/Feb  2:11pm +01] wrote:

To my mind there isn't a specific workflow here, but just how tag2upload
is always meant to work.  So I'm not completely sure what you mean.

But possibly #1105759 is of interest.

Thanks, I added the following to https://wiki.debian.org/tag2upload

   If you see "git-debpush: found upstream tags: v0.4.0 upstream/0.4.0
   git-debpush: use --upstream=TAG to say which one to use": This can
   occur if you are pushing from a repository that has tags both from
   upstream (i.e., v0.4.0) and tags generated by gbp (i.e.,
   upstream/0.4.0). By specifying --upstream=v0.4.0 you will make
   tag2upload use the upstream's git SHA1 commit. However this does not
   always work, and using --upstream=upstream/0.4.0 is more reliable,
   but then the upstream git SHA1 commit information will not be
   recorded in the signed tag2upload tag. The following situations does
   not handle the --upstream=v0.4.0 approach: 1) For +dfsg or +ds
   packages that make intentional modifications to upstream source
   before use, 2) Packages using .gitattributes export-subst to cause
   upstream source tarballs to contain additional information, and you
   chose to not work around this, 3) Upstream does not produce any tags
   at all, and the Debian packaging follows a git commit
   (DebianBug:1127411).

I most likely got terminology and deeper knowledge confused, and maybe
this particular error case is not common enough to warrant being
mentioned at all, so feel free to remove/modify however you like.

I have adopted a preference to use the --upstream=v0.4.0 style because I
believe it conveys a stronger cryptographic binding to upstream git
source code than --upstream=upstream/0.4.0 which only binds to the
actual upstream git commit hash indirectly via git merkle properties,
which are subject to manipulation by non-upstream Debian maintainers.

Interestingly, I've noticed that you can use --upstream=v0.4.0 for one
upload and --upstream=upstream/0.4.0 for the next upload for the same
upstream package version.  I'm not sure if this is because tag2upload
syntheisze the exact same orig.tar or if it works because tag2upload
will use whatever orig.tar from the archive on subsequent uploads.  This
situation seems intuitively a bit weird, but I don't immediately see
what could go wrong.

/Simon