Follow-up to #53 (closed via `PGXN_REMOTE`). That fix requires a maintainer to remember to pass `PGXN_REMOTE=upstream` (or whatever) every time, on every affected target (`tag`/`rmtag`/`forcetag`/`dist`). It's an opt-in escape hatch, not a guard -- someone who forgets still silently tags the wrong remote, which is exactly the failure mode #53 was filed over in the first place (cat_tools' 0.2.3 release tag landed on the maintainer's fork instead of `Postgres-Extensions/cat_tools`).
Proposal
In an ideal world, pgxntool would try to determine whether the default remote (`origin`, or whatever `PGXN_REMOTE` resolves to) actually points at the project's true source of truth, and warn (or refuse) when it looks like it doesn't -- rather than relying entirely on the maintainer remembering to override it correctly every time.
This is inherently heuristic (pgxntool has no authoritative way to know which remote is "canonical" for an arbitrary project), but some possible signals:
- Compare the remote's URL against the one recorded in `META.json`/`META.in.json` (if extensions reliably record a canonical repo URL there).
- If more than one remote exists, and the target remote's URL differs from all others in a way that looks like an owner/org mismatch (e.g. `PGXN_REMOTE` resolves to a URL under a different GitHub user/org than a remote literally named `upstream`), print a confirmation prompt or a loud warning before pushing.
- At minimum, always print which remote (name + URL) a tag/dist push is about to hit, so a maintainer skimming output has a chance to notice before it happens, rather than finding out after the fact via `git ls-remote`.
Not asking for a specific implementation here -- flagging the gap since #53's fix only helps if you already know to use it, and the whole point of the original bug report was that nobody realized there was anything to know until it had already gone wrong once.
Found while syncing cat_tools to pgxntool 2.2.0 and writing up `PGXN_REMOTE` usage in cat_tools' own release checklist: Postgres-Extensions/cat_tools#52.
Follow-up to #53 (closed via `PGXN_REMOTE`). That fix requires a maintainer to remember to pass `PGXN_REMOTE=upstream` (or whatever) every time, on every affected target (`tag`/`rmtag`/`forcetag`/`dist`). It's an opt-in escape hatch, not a guard -- someone who forgets still silently tags the wrong remote, which is exactly the failure mode #53 was filed over in the first place (cat_tools' 0.2.3 release tag landed on the maintainer's fork instead of `Postgres-Extensions/cat_tools`).
Proposal
In an ideal world, pgxntool would try to determine whether the default remote (`origin`, or whatever `PGXN_REMOTE` resolves to) actually points at the project's true source of truth, and warn (or refuse) when it looks like it doesn't -- rather than relying entirely on the maintainer remembering to override it correctly every time.
This is inherently heuristic (pgxntool has no authoritative way to know which remote is "canonical" for an arbitrary project), but some possible signals:
Not asking for a specific implementation here -- flagging the gap since #53's fix only helps if you already know to use it, and the whole point of the original bug report was that nobody realized there was anything to know until it had already gone wrong once.
Found while syncing cat_tools to pgxntool 2.2.0 and writing up `PGXN_REMOTE` usage in cat_tools' own release checklist: Postgres-Extensions/cat_tools#52.