Happy holidays, all! On Dec 24, 2025, at 19:48, Russ Allbery <[email protected]> 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 :-)
