Otto Kekäläinen writes ("Re: Include git commit id and git tree id in *.changes
files when uploading?"):
> I think it is common sense that other tools can also use the fields
> Git-Tag-Tagger and Git-Tag-Info as long as they follow the same
> semantics.
Yes, *BUT* currently the only tool that has these semantics is
tag2upload.
This is because the semantics are:
"The PGP signatures on this upload do not tell you which human
made this upload.
"Instead, if you need to know which developer made this change,
use the information in the Git-Tag-* fields."
Any future tool that had similar semantics ought to use these fields.
But such a thing would be a centralised service, because its package
signging key would (i) not belong to a human (ii) have to be trusted
by dak.
Lucas Nussbaum writes ("Re: Include git commit id and git tree id in *.changes
files when uploading?"):
> I don't think that's a fair characterization of what happened around
> Git-Tag-*. If we are looking for people to blame, we should blame
> people like me who now think it's a good idea to generalize the scope of
> those fields outside of the tag2upload context, but did not follow the
> tag2upload discussions closely enough to raise that point when it was a
> good time to do it.
It's quite sensible to think about expanding the usage of metadata
fields to other contexts with the same semantics. But, I think there
is a misunderstanding about what those semantics are. See above.
(Such a misunderstanding is hardly surprising given how complex
everything is nowadays, and no blame lies with anyone about that.)
Thanks,
Ian.
