Hi, > >It would probably be a better practice if the upstream developer > >gpg-signed the auto-generated tarball. > > ... except in the cases where the auto-generated tarball is not what the > upstream developer wants to be releasing, but Github won't allow them to > turn it off. > > Some typical examples of reasons why a git-using upstream wants to > release their own canonical source artifact that is not a `git archive`: > > - they want generated files to be added, especially for Autotools > projects > - or the opposite: they want to omit something that is in upstream git > but less useful downstream, like a large test dataset, or non-Free > files, or an alternative build system that is not relevant on Unix > - or they want some version marker to be added, like git-version-gen's > .tarball-version, SDL's REVISION.txt or anything analogous, so that the > tarball is self-identifying without .git and still knows its own version > number (possibly without needing manual edit/commit at release time) > - or they want submodules to be converted into subtrees, or some other > mechanism for adding (or removing) subprojects
This is a good list, and may I add that the .gitattributes may also include Git LFS configurations or custom conversions which complicate the ability to cleanly export the contents on any arbitrary machine with no network access. And of course, not all upstreams use git, although the market share of CVS, Mercurial etc is nowaways tiny. Newer systems like Juju still use a git-compatible object/file structure so they might work with the general assumptions of git, but they too might have special extra configs. Just saying that while it is very nice to work in an ecosystem with all my upstreams and git and all my Debian packages are in git, there are still corner cases that force the lowest common denominator to be a tarball of files. And if and when importing tarballs I would very much like to see the ability to use pristine-tar and detaches signatures (which is another thread). Going back to the first message in this thread, when I suggested it would be nice to have the git commit id and git tree id embedded in the Debian source package as an audit trail of what was the state of the Debian packaging repository, I was specifically assuming that the Debian packaging is being maintained in git and that is something we could achieve at 100% if we want to. If we want to jump directly from the Debian source package to verify the *upstream* git commit id and git tree id, there should be more fields to allow it. Eg. Git-Commit-Id, Git-Tree-Id, Git-Commit-Id-Orig and Git-Tree-Id-Orig.
