Use redirect.github.com links when creating Fixes, Refs, PR-URL and Backport-PR-URL

[joyeecheung]

Sometimes I get bothered by the cross references automatically created by GitHub cluttering the referenced PR/issue, especially when they get copied into various forks and each fork would generate a new cross reference. Then the thread of the referenced PRs/issues would eventually get drowned by these cross references over time.

I learned from Bluesky that the documented way to prevent this from happening is to use redirect.github.com instead. So it seems helpful to use that in the metadata generated for commit messages. We can still create direct cross references when we reference them in a comment/PR description, which don't usually get copied all over the place in a way out of our control.

cc @nodejs/tsc @nodejs/release @nodejs/build for visibility since it'll impact the formatting of commit messages, not sure if that'll break anything..

[richardlau]

cc @nodejs/tsc @nodejs/release @nodejs/build for visibility since it'll impact the formatting of commit messages, not sure if that'll break anything..

I think it'll affect branch-diff/changelog-maker (I think branch-diff uses changelog-maker to process commit messages but it has been a while since I last looked).

I also think we had regular expressions for github.com links in core-validate-commit.

For release, having the cross references helps to eyeball which release lines a PR has landed on. That should be okay as long as the release proposal PRs link to the PRs, which at the moment comes from the PR descriptions being based on the changelog generated by changelog-maker.

[marco-ippolito]

I actually like the cross reference and I check them to see if one of my PRs broke projects (that's how I found out about type stripping breakages in Node v24). Can we make it optional?

[joyeecheung]

I think it'll affect branch-diff/changelog-maker (I think branch-diff uses changelog-maker to process commit messages but it has been a while since I last looked).
I also think we had regular expressions for github.com links in core-validate-commit.

Thanks, I think we should double check though if the regexp is lenient enough to not exclude subdomains, that might be fine..but still worth checking.

That should be okay as long as the release proposal PRs link to the PRs, which at the moment comes from the PR descriptions being based on the changelog generated by changelog-maker.

That's something I find useful too but I think most of the time I am looking for the bigger and bolder cross reference generated from the PR descriptions, and almost never the bunch of smaller references below from the commit messages..that also create a lot of duplicates.

[joyeecheung]

I actually like the cross reference and I check them to see if one of my PRs broke projects (that's how I found out about type stripping breakages in Node v24). Can we make it optional?

I think you are talking about cross references from other projects? This one is talking about the links in commit messages that lands in nodejs/node. Other projects can still link to our PRs freely from github.com as they choose. Unless they cherry-pick Node.js commits, including the commit messages as-is, into their repository, it probably won't affect anything, and I think in those cases the cross references are the ones we want to avoid (e.g. from various forks). They can still create a direct link in their own commit messages or thread, as long as they are not copying commit messages of Node.js verbatim somehow (which I think is very rare)

[joyeecheung]

Taking https://redirect.github.com/nodejs/node/pull/56350 as an example:

I think what you are trying to see are the cross references from other projects there. Those won't be affected, as they are writing the links on their own, not copying our commit messages. What's going to be gone are the ones from commits (all are technically duplicate information in that PR). So the effect would be:

Which seems ideal. Note that the release cross reference is still there, from the PR, but not from the commit which was duplicated 3 times due to the copying of the commit messages in forks and branches.

[richardlau]

That should be okay as long as the release proposal PRs link to the PRs, which at the moment comes from the PR descriptions being based on the changelog generated by changelog-maker.

That's something I find useful too but I think most of the time I am looking for the bigger and bolder cross reference generated from the PR descriptions, and almost never the bunch of smaller references below from the commit messages..that also create a lot of duplicates.

For clarity, let's take for example, nodejs/node#57477, as a releaser it is helpful to have these sorts of references:

indicating that the PR either landed in (or was considered for inclusion in) the Node.js 22.15.0 proposal. And I think these are coming from the release proposal descriptions, which in turn are copy/pastes from the changelog (which will be based on output from changelog-maker, which in turn grabs that data from the PR-URLs from commit metadata).

I'm less concerned with the references from commits, which is the problem attempting to be solved by the proposal. I just want to make sure we don't lose the above.

[joyeecheung]

I just want to make sure we don't lose the above.

Yes, that's the "the bigger and bolder cross reference" I was mentioning. I think that can still be implemented as long as the changelog maker strips out the redirect. part from the URLs?

[richardlau]

I just want to make sure we don't lose the above.

Yes, that's the "the bigger and bolder cross reference" I was mentioning. I think that can still be implemented as long as the changelog maker strips out the redirect. part from the URLs?

Yes, I think so.