I have developed a package i.e:
abc and it is stored in a private gitlab instance. The latest version is imported into my program and works as expected. I recently needed to make some changes to the package and I assumed I could create a new branch
f1 and test package
abc by retrieving that specific branch/version as follows:
$ GOPRIVATE="gitlabprivate.com" go mod edit -require gitlabprivate.com/workspace/abc@f1
$ GOPRIVATE="gitlabprivate.com" go get -u
However, this fail with:
abc at latest version v0.0.0-20200407120314-666552805e7a but not at required version v0.0.0-20200416000117-e07f205569a2
666552805e7a being the master/latest version. The version/branch I require
e07f205569a2 has been downloaded to my module path but it is not available to my program.
How do I get this to work but more importantly what is the correct procedure to work with locally developed packages?
The thing is your
require command is asking the go module to fetch branch
f1, not the latest version, commit id, tag ID, or other branches that has the latest versions (
master?). If you arrange your
f1 to the latest and greatest, it should be able to fetch the latest commit id.
It’s more on how you manage your repository structure. You can follow Debian delivery practices:
test release (for next
sid release (bleeding edge)
release-vX-Y-Z = specific version releases via branch fetch
I see what you’re saying but
f1 is actually based off the
master branch and has the most recent commits.
I also experiment by removing the
go.mod entry and running
go get directly:
$ GOPRIVATE="gitlabprivate.com" go get gitlabprivate.com/workspace/abc@f1
I imagine this should remove any concerns about what is
latest but it resulted in the same error. I’m now confused as to why it is even aware of version
You need to check the
gocache to see whether the downloaded git branch is exactly the same as your main repository. As far as I understand,
666552805e7a is go mod pseudo version number which generally makes not much of sense just by staring at it.
f1 to me is the same as
release-vX-Y-Z in my context. It’s a fixed version of your software.
go get will fetch that branch as it is. What I meant was say if you want latest and greatest, you probably want to arrange the branch managements accordingly. So in my context, I will
@next for bleeding edge.
Don’t worry, I still use branch release for
go get over the tagging because the
v2, v3, ..., vN directory enforcement policy is really making a mess in the repository.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.