Patrick Gaskin

Changing my GitHub username to @pgaskin

For the last year, I have been planning to switch my username to @pgaskin. I finally decided to do it today, and am writing about my experience in case anybody else finds it useful.


The GitHub username switch itself went quite well. Almost everything is handled properly, and there weren’t any major side-effects.

Most of the things I was concerned about turned out well (but there wasn’t any documentation about it):

  • Issue/PR/commit references (both absolute like geek1011/repo#1 and relative like repo#1 or #1) in comments are redirected in the GUI. The original message remains the same, but the link and the link text is updated dynamically to point to the new repo.
  • The same thing happens with references in commit messages (e.g.
  • Filtering commits by the author still works, as long as the email address is associated with your account.
  • Links to repositories are redirected (including deep links), but user profiles are not.
  • The user profile contributions graph remains the same.
  • GitHub Actions works fine.
  • Git pushes are redirected, both over SSH and HTTP.
  • Release download links (e.g. are redirected.
  • Pull requests are edited to point to the new user automatically (i.e. the PR itself is modified, it isn’t just shown differently like with issue/PR/commit references).
  • The API redirects repositories from URLs like to
  • The dashboard didn’t break.

Some things only partly worked or needed manual work to fix:

  • Gists are not redirected (but stars still remain).
  • The contributor list in the new-style sidebar (the one in the July 2020 redesign) will not get updated until something causes GH’s cache to be cleared (e.g. changing the repo sidebar settings or description). This is a bug on GitHub’s side.
  • If a private email in the form is used to commit, the ID takes precedence and is linked to your new username. If one in the form (e.g. before July 2017) is used, the commit is not linked to your new username (it still counts as your contribution on the user graph, but not the repo insights). If your own email address is used, nothing changes. This is inherent with the way Git works, so there isn’t much that can be done if was used.
  • Docker images in GitHub Packages are renamed, but not redirected.

Some things didn’t:

  • User profiles are not redirected.
  • User mentions are not updated or redirected.

All in all, I was pretty happy with the way this was handled.

GitHub Pages

Upon changing my username, GitHub triggered a page rebuild for all repositories. Unfortunately, this doesn’t work on archived repositories, and I received a few emails about page build errors for those.

I also needed to rename my repository to for the pages and custom domains to work properly.

Since I use a custom domain, I didn’t have any other issues with the switch.

Drone CI

The process for Drone was relatively straightforward. Since the webhooks installed on the repositories do not include any repository-specific data in the hook URL, the only thing I needed to do was make Drone aware of the new username.

This turned out to be as simple as logging in and out, then pressing SYNC to update the usernames for the GitHub repositories (before pressing sync, the webhooks failed due to the repository not being found).

After this, everything worked well and the old build logs were retained, but links to the build logs under the old username now lead to a 404 error.

Note that this only works on Drone v1.0.0 and newer (see drone/drone#2167).


Some of my projects use AppVeyor for CI. In the past, this used webhooks and OAuth for linking to GitHub, but it now uses GitHub Apps. Even then, the change wasn’t as simple as it should have been.

The first issue was logging in. The GitHub login didn’t work (it showed an error about the email already being in use on another AppVeyor account) due to the GitHub login being tracked based on the username. To fix this, I needed to add a normal login option by using the password reset, then unlink and re-link my GitHub account. I was then able to log in successfully, but my builds still wouldn’t trigger.

The next issue was updating the repository settings. This was a bit trickier, as AppVeyor still thought it was installed on my old account’s username. To fix this, I needed to go to the integration settings, and re-add AppVeyor. The process for doing this wasn’t obvious. First, I needed to press the New Project button, click on GitHub as the source, then press Revoke access. I had originally tried using Update installations, but this didn’t change anything. To restore the projects, I needed to press Import existing installations rather than Install app.

After that, I needed to change the GitHub project username in the settings for each project.

In the end, everything worked fine and the old build logs were retained. Luckily, the URLs are independent of the GitHub username, so nothing needed to change there.

Travis CI

Travis CI handled the username change more smoothly than AppVeyor and Drone. After logging out and back in, the repository list updated itself to match, and everything worked fine from there on.

Note that even though the old build logs were retained, the links to them weren’t redirected.

Docker Hub

Docker Hub doesn’t appear to even be aware of username changes. After changing my username, Docker Hub builds stopped triggering. I ended up disabling and re-enabling automated builds (this requires setting up build rules again, as they aren’t preserved).

Go Modules

Go uses the GitHub repository URL as an import path and unique identifier. As such, this is the part I was the most worried about, but in the end, this went quite a bit smoother than expected.

Note: One workaround would have been to use vanity import URLs, but for various reasons, I decided not to do so for now.

The first thing I tested after changing the username is whether things would still build as-is when referenced by the old module name. Fortunately, the GitHub redirect seems to be honored without errors, both with and without the Go module proxy/cache.

Next, I updated the module names and released new versions where appropriate. Then, I confirmed that everything would build under both the old and new module names. Everything worked fine other than interoperability between packages referencing the old/new module names, which were treated as separate modules (the same way as with major module versions). I also ensured that trying to reference the new version from the old module name would fail, and vice versa.

Finally, I checked, which treated the old/new module names as separate modules like I expected.


Google hasn’t picked up the change yet, so I can’t comment on this at the moment.


On the whole, my username switch went quite a bit better than I had expected, but there were still multiple areas which could have used improvement.

For GitHub itself, I believe everything went as smoothly as possible. The redirects worked well, and the entire process was quite straightforward. I was pleasantly surprised when absolute commit and issue references updated themselves in the GUI, even when part of something read-only like a commit message (e.g. username/repo@commit or username/repo#issue in a commit message or comment). It would be nice if user mentions were also updated, but I worked around that by creating a dummy user with my old username.

For Drone CI, it would have been easier if a repository list sync was triggered upon a username change during login. This would have prevented webhooks from temporarily failing after the username switch. It would also be nice to have redirects which work the same way as GitHub repository ones.

For AppVeyor, it would have worked better if linked logins were tracked using the user ID rather than the username, and if the GitHub App had automatically detected username changes and updated the project name accordingly. I haven’t tested what happens if a repository is renamed without changing the username. One thing I did like was that the AppVeyor username was independent of the GitHub one.

For Travis CI, everything was as good as it gets, other than the lack of redirects from the old username.

For Docker Hub, it would be nice if there was an easier way to update the automated build settings.

I have mixed feelings about Go modules. Using vanity import URLs would have worked well if I had used them from the start. Even though I didn’t, the process went smoothly and old stuff didn’t break in general. I wish had a mechanism for redirecting the documentation, and I wish there was a way to provide a smooth upgrade when changing the import path, but it’s understandable why it works the way it does. Overall, I like the decentralized mechanism for Go imports, but it does come with complications like these. TODO: more

That pretty much sums up my experience changing my GitHub username from @geek1011 to @pgaskin.