I recently had to move private repositories from SaaS Gitlab to an on-premise version. Everything was going well where I did:
- Update old go module paths in repo
a
fromold.com/workspace/a
tonew.com/workspace/a
- Add a new tag
v1.2.3-new
to the latest commit - Update repo
b
to reference latest tagv1.2.3-new
fromnew.com/workspace/a
- Run
go mod tidy
in repob
and verify it works
Now I have a requirement to reference an older version tag of new.com/workspace/a
(originally old.com/workspace/a
). So in repo a
, I checked out the older tag, fixed up the module path to new.com/workspace/a
from old.com/workspace/a
and tagged it as v1.1.1-new
.
In repo b
then I referenced new.com/workspace/a
with v1.1.1-new
. However, this results in:
go: new.com/workspace/[email protected]: parsing go.mod:
module declares its path as: old.com/workspace/b
but was required as: new.com/workspace/b
If I check the v1.1.1-new
tag in repo a
, the module path is set correctly in the go.mod
file:
module new.com/workspace/a
It is unclear to me why it works with the tag v1.2.3-new
on the latest commit but fails when I reference an older commit.
CodePudding user response:
So I can't say I fully understood why this worked but here are the steps that made it work (including what didn't).
I resorted to clearing the cache with
go clean -modcache
Tested with the following but it still failed.
go get new.com/workspace/[email protected]
As per my comment in the original question, this worked via the
v1.1.1-new
commit hash So I resorted to that again.go get new.com/workspace/a@27ca81f7
Now it picked up the version for that commit and was successful. The
go.mod
file was also correctly updated with the tag/version despite using the commit hash in thego get
command.new.com/workspace/a v1.1.1-new