From: simon@josefsson.org   
      
   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   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmK+5cUHHNpbW9uQGpv   
   c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f   
   V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z   
   ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh   
   BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA   
   /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx   
   +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx   
   I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0   
   +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R   
   cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE   
   8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J   
   ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6   
   qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB   
   BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA   
   JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF   
   PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh   
   is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFohisAPwP0NdtbydQ   
   xdcWz6Rpv0j0IESVhC6OQGyjlqx6n4sVDQEAkI+/+Fup30OmMJkpVht8sfiMX4Hb   
   qW080tXLjSgjnA0=   
   =aEjG   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)