Broken urls in npm registry

[xtqqczze]

https://www.npmjs.com/package/remark-lint
https://www.npmjs.com/package/remark-preset-lint-recommended
...etc.

https://github.com/remarkjs/remark-lint/tree/master/packages/remark-lint -> 404
https://github.com/remarkjs/remark-lint/tree/master/packages/remark-preset-lint-recommended -> 404
...etc.

[xtqqczze]

This issue could be fixed by mirroring master and main branches:
https://github.com/chancancode/branch-rename/#phase-1-mirror-master-and-main

[wooorm]

Thanks, fixed in 750541e!

[xtqqczze]

The repository links in the npm registry are fixed, are still broken elsewhere, for example the upstream url at:
https://aur.archlinux.org/packages/remark-lint/

Perhaps you could consider my suggestion from #239 (comment), at least temporarily.

[ljharb]

It can also be fixed by using “HEAD” instead of hardcoding a default branch name in the links.

[xtqqczze]

@ljharb I thought HEAD was just a pointer to the last commit made, which might not be associated with the default branch. For example if you push some commits to unstable branch, HEAD would point to the tip of that branch and not the default branch.

[ljharb]

the prose term “head” can mean that, but in git and GitHub, HEAD is a repo-wide pointer to one ref (generally the default branch)

[wooorm]

Hi Jordan, nice to see you here! 👋

---

Background: I’ve been recently renaming ±400 repos from master to main. What I did is change links to use main when pointing to the project itself, and to use HEAD when pointing to other repos. I am under the impression that HEAD on GH points to the last commit on the default branch, not the latest commit.

Mirror: That would prevent people from updating links. I doubt that the Arch project would change to the new branch. Resulting in the same problem in a couple of years when we would stop mirroring. As this is a time when more projects are changing, I am under the impression that this is the best time to get other folks to update too (as they might assume something like main or primary or whatnot)

GitHub: I know that GH is working to change master. I am not sure what or how that would work: One part I’m hoping on is that they’d redirect from master, if it doesn’t exist, to the default branch. I don’t know what their plans are, I don’t have any influence there, but that seems reasonable.

---

I’d say let it be the way it is (in this project). I changed the name on purpose.

[ljharb]

I'm in favor of changing the name; I'm saying that you can use "HEAD" in any URLs and it will point to whatever the default branch is, and then the URLs are robust against renaming the default branch :-)

[wooorm]

Ohh sorry, yes I think we agree on that! The rest of the comment was more towards @xtqqczze, and some extra general info!

[wooorm]

For folks reading along or stumbling on this in the future: GH now has some form of aliasing from master, when missing, to the default branch: https://github.com/github/renaming/

[ljharb]

Specifically, it says that all the features required for a seamless rename won’t be available until later this year.

[xtqqczze]

Github has announced that links to deleted branches will now redirect to the default branch: https://github.blog/changelog/2020-07-17-links-to-deleted-branches-now-redirect-to-the-default-branch/.

Based on the explanation on the Github blog post and my own testing it appears that as of today this is not the case for tree links like those documented in this issue, only blob links:

follow https://github.com/remarkjs/remark-lint/tree/master/packages/remark-lint
https://github.com/remarkjs/remark-lint/tree/master/packages/remark-lint -> 404

follow https://github.com/remarkjs/remark-lint/blob/master/packages/remark-lint
https://github.com/remarkjs/remark-lint/blob/master/packages/remark-lint -> 302

https://github.com/github/renaming
https://github.com/remarkjs/remark-lint/blob/main/packages/remark-lint -> 301
https://github.com/remarkjs/remark-lint/tree/main/packages/remark-lint -> 200

github/renaming has not enabled issues so I have documented my findings in this issue for future reference.