go-import meta tag should preserve requested path for redirected projects

Release notes

Go module imports now work correctly for projects that have been moved or renamed.

Problem to solve

When a Go project is moved/renamed in GitLab, the go-import meta tag returns the new canonical path instead of the requested path. This causes go get to fail with "meta tag did not match import path".

Example:

• Project moved from gitlab.com/org/repo to gitlab.com/org/subgroup/repo
• Request: https://gitlab.com/org/repo?go-get=1
• Current response: <meta name="go-import" content="gitlab.com/org/subgroup/repo git ...">
• Go fails because requested path doesn't match meta tag

Proposal

In lib/gitlab/middleware/go.rb, when handling a request that came via redirect, return the requested path as the import prefix while the repo URL points to the actual location:

<meta name="go-import" content="gitlab.com/org/repo git https://gitlab.com/org/subgroup/repo.git">

This is standard Go behavior - the import-prefix and repo-root are designed to be different. From go help importpath:

│ │ the go tool will verify that https://example.org/?go-get=1 contains the same meta tag and then download the code from the Git repository at https://code.org/r/p/exproj

This is the same mechanism that powers vanity imports like golang.org/x/tools → github.com/golang/tools.

Intended users

Teams using Go modules who need to reorganize their GitLab namespace structure without breaking existing consumers.

Feature Usage Metrics

Could track: count of ?go-get=1 requests served via redirect paths.

Does this feature require an audit event?

No