Sean Whitton <[email protected]> writes: > Hello, > > Simon Josefsson [08/Jan 1:09pm +01] wrote: >> Doesn't it? 'gbp import-orig --uscan --upstream-vcs-tag=v1.2.3' will >> fail with a hard error if v1.2.3 cannot be found and imported to the >> upstream branch. Isn't that the property you want? > > But if the contents of the tarball differs from the contents of the > upstream tag, the contents of the tarball takes precedence. There isn't > a way to tell GBP to error out, in that case (which Ian and I would > argue ought to be the default). Instead, it unconditionally goes ahead > and makes a commit on top of the upstream tag representing the > differences.
Ouch. I agree that should be improved. >> Maybe it helps to realize to understand where I'm coming from to is to >> see that I worry about long-term authenticity and reproducibility of >> bit-by-bit identical release artifacts. >> >> A PGP signature on a 'git archive' tarball is the closest I'm coming to >> solve my concern, so pending anything better, that's what I will >> recommend. >> >> If there is a way to implement something with that property with native >> git, I would happily give up tarballs. > > AIUI the file format used by git-bundle(1) is stable and documented. Sure, but not how to generate one reproducibly for a particular commit at a later point in time when the git repository has seen other activity. We know how to do that with tarballs and even for images of file systems like ext4. Achieving this for git bundles is feasible, but I've been unable to find a idiom to use for the past year or two. /Simon
signature.asc
Description: PGP signature
