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

Attachment: signature.asc
Description: PGP signature

Reply via email to