CC @bcmills

@jayconrod @matloob too via owners. https://dev.golang.org/owners

Just to confirm my understanding, is your intent to permanently change the module path (what we internally call a hard fork) or to temporarily fetch the module code from another location (soft fork)?

Soft forks are commonly used to make small changes, sometimes intended to be upstreamed. A replace directive is the right tool for that:

replace github.com/org/dep v0.0.0-20210410204338-0d7a392d906a => gitlab.com/org/dep v0.0.0-20210410204338-0d7a392d906a

You can add or remove replace directives with go mod edit.

Hard forks are more complicated. I wouldn't expect go get to be able to deal with this situation, since it requires not only changing the module path in go.mod upstream, but it also requires changing imports in your packages to use the new module path.

I think what is happening here is:

1. The hand-edit adds a requirement on gitlab.com/org/dep v0.0.0-20210410204338-0d7a392d906a, which fails to load due to a mismatched module path. (At that commit, the go.mod file still declares the github.com/org/dep path.)
2. go get reports the mismatched module path as an error, because it is trying to preserve transitive dependencies of the existing requirement graph. (It can successfully identify gitlab.com/org/dep@latest, but it can't figure out how to incorporate that into the requirement graph because the graph is broken.)

I'm making the module loader more tolerant to errors for #36460, and I wonder to what extent this problem will go away with lazy loading. If we know we're upgrading to gitlab.com/org/dep@latest, and we can tolerate a broken module graph up until we add that upgrade, and we're in a lazy module so we get to assume that the transitive dependencies of the old path don't matter, then we should be able to do the upgrade without bothering to report the error for the (no-longer-relevant) old version.

TL;DR: I'm hopeful that #36460 will solve this, but I ought to revisit this scenario when that feature is complete to double-check.

Just to confirm my understanding, is your intent to permanently change the module path (what we internally call a hard fork) or to temporarily fetch the module code from another location (soft fork)?

Sorry for the late reply here. Yes, I'm permanently changing the module path, but the upstream module's imports have already been adjusted from import "github.com/org/dep" to import "gitlab.com/org/dep".

So both github.com/org/dep and gitlab.com/org/dep are valid go-gettable modules, the only difference is the version. The gitlab repository was created after the github one, so the version number will be different.

I don't know what the gitlab version number is yet, so I expected to be able to run go get -u gitlab.com/org/dep or go get -u gitlab.com/org/dep@sha and it would sort it out for me.

Instead, because I have the old github version number, it's failing. This is probably the correct behavior in most cases because the version isn't valid for the gitlab repo, but I understand the meaning of go get -u to upgrade the dependency, so in this specific case, I don't think it should matter if the existing version in go.mod is invalid or incorrect.