Re: Include git commit id and git tree id in *.changes files when uploading? [and 1 more messages]
Happy holidays, all!
On Dec 24, 2025, at 19:48, Russ Allbery <rra@debian.org> wrote:
> I don't think that's what Ian is saying. I think they're saying that the
> semantics are specific to an automated upload service that acts on signed
> tags, which is different from a manual upload by the maintainer.
>
>> If I would do a manual upload, and add these two fields correctly, that
>> is, Git-Tag-Tagger: my name/email and Git-Tag-Info: pointing to a
>> signed (by me) tag, I don't see how this wuold conflict with with the
>> meaning of the fields when filled by tag2upload. The signature on the
>> changes file would be mine, but that would be the only difference.
>
> The semantics are subtlely different.
“Dumb” question here: isn’t the subtleness coming from the baked-in assumption that *only* tag2upload may use it and nothing else is allowed to?
> The field is defined to point to the signed tag that triggered an upload
> via an automated process.
Ah, there’s what I missed on first read-through: these are spec'ed for tool-use only. Yet the fields are not obviously named as off-limits for non-tool-use. Hmm.
How about making visible that tooling is involved and expected/desired, not manual uploading? (Inventing a name here) “X-Upload-Helper: tag2upload” in relevant control file, then tag2upload refuses to upload anything with X-Upload-Helper missing, empty, or not 'tag2upload’. Other tools playing in the same space can pile on. And Git-Tag-* fields can be re-spec’ed as usable manually and compatibly to how tools interpret it.
I remember playing around with n analogous scheme back in my Yahoo days, just after the turn of the century. [further ramble elided]
Apologies for revisiting if I missed earlier discussion where this was brought up and beaten out in the solution space.
Thanks!
— Joseph Beckenbach
lurker, nostalgic about email addresses with bangs not ats, graybeard but shorn when my wife’s not traveling :-)
Reply to: