Lucas Nussbaum writes ("Re: Include git commit id and git tree id in *.changes
files when uploading?"):
> The information provided by Git-Tag-Info is that the source package was
> generated from a given git commit. This could be true whether the source
> package was generated by the tag2upload service, or whether it was
> generated locally by the maintainer. So I don't see why that field could
> not be generalized to locally-generated source packages.
No, that doesn't make sense.
The primary point of Git-Tag-Info is to allow legacy systems that must
work with .changes files (such as dak) to find out which human
uploader intended the upload. This is necessary with tag2upload
because the .dsc and .changes are signed not by the uploader, but by
the tag2upload service.
For a non-tag2upload upload, this information is simply in the
.changes signature and no additional field is needed.
gi-based systems can trace the git tags via the git information in the
git depository, which includes the uploader's tag, and for tag2upload,
the maintainer's signed tag for the version in question. All of this
information is in git.
If you want to trace a source package from dsc back to git, you need
the Dgit field. And the Dgit field *is* added locally by dgit push
(and dgit is very careful to check that what it writes in the Dgit
field is actually true: in partgicular that the referenced git tree is
treesame to the results of dpkg-source -x (without .pc directory)).
So, no, Git-Tag-Info ought not to be generated by human-driven upload
tools.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
