Transfer/rename a GitHub repository without breaking elm-package

In the spirit of literal package names, I’m planning to rename my opensolid/geometry package to ianmackenzie/elm-geometry. Ideally, I would do this by transferring the repository to my own user account and then renaming it so that I retain issues, pull requests etc., but I want to make sure that I don’t break package downloading for anyone using the existing package! GitHub does apparently forward all requests from the old repository to the new (https://help.github.com/articles/about-repository-transfers/) but I’m worried about a couple things:

  • Does elm-package do anything weird that might circumvent or not respect GitHub’s redirects?
  • What happens with a transfer + rename? It doesn’t look like I can do it in one step, I’ll have to transfer opensolid/geometry to ianmackenzie/geometry and then rename that to ianmackenzie/elm-geometry. Either one of those steps individually does set up a redirect (https://help.github.com/articles/renaming-a-repository/) but I’m worried that two levels of redirection might break something.

Anyone have experience with doing something like this? Any suggestions for other approaches? (One thing I thought of would be to do the transfer + rename, then fork the renamed repository back to a new opensolid/geometry repository so anything URL-based should still work.)

4 Likes

Hey. I’m guessing I have the most experience on this topic! Url redirects will not work, as they do not work with the way zips are downloaded.

What i recommend you do is move the package, then fork it back to the original location. That way users still end up at the right package issues (since they can see on github that it’s a fork) and elm-package will still work.

1 Like

Check out the migration checklist for elm-community as the same applies: https://github.com/elm-community/Manifesto/blob/master/migration_checklist.md

1 Like

Many thanks @eeue56, that is exactly what I needed to know! I also just realized that a redirect wouldn’t work anyways, as I’ll need to delete the version tags in the new repo so I can start again at 1.0. So it looks like transfer, rename and fork back is the way to go. Hopefully nobody tries to download opensolid/geometry during the few minutes that it won’t exist =)

I just did a simple rename (rather than transferring to a different Github user or organization). It turns out Github doesn’t let you fork your own repo. But I still needed to preserve the tags so that users could install package versions with the original name.

Following these Github instructions for duplicating a repo did the trick for me. Unfortunately you don’t get the text at the top of the repo with the old name saying that it is a fork. As a workaround I just edited the project link and description to explain that it is an old repo.