Go's design encourages developers to use git hosting locations directly in import paths, such as 'github.com/thetrueares/boneclone', which makes it easy to fetch code and report bugs but creates tight coupling to the hosting provider. As Iain Cambridge explains in his blog post, this means moving from GitHub to GitLab or Azure DevOps requires changing every import statement in the codebase—a process that can be so burdensome that some companies maintain multiple hosting platforms simultaneously just to avoid the migration overhead.
The solution involves using custom domains for Go import paths, configured with specific HTTP responses that guide the Go tool to the actual code repository. As demonstrated in the blog post's nginx and HTML examples, a domain like go.iain.rocks can be set up to respond to Go tool requests (with ?go-get=1 parameter) by serving meta tags that specify the real git location, while redirecting regular web visitors to the GitHub repository. This approach allows teams to change their underlying git hosting provider without modifying any import paths in their Go code.
The blog post provides concrete configuration examples. The nginx server block checks for the 'go-get=1' query string: if absent, it issues a permanent redirect to the GitHub repository; if present, it serves an HTML file containing two meta tags. The 'go-import' tag specifies the custom domain, the version control system (git), and the actual repository URL. The 'go-source' tag provides links for documentation, allowing the Go tool to fetch the code from the correct location while presenting a consistent import path to developers.