Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: specifying module branch writes incorrect version tag to go.mod #31287

Open
paulbdavis opened this Issue Apr 5, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@paulbdavis
Copy link

commented Apr 5, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.1 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

Create a new go module

Getting a module by branch for testing using:

go get github.com/paulbdavis/go-version-issue@feature/branch

The repo has the branches set up as follows

86fe9a2 * origin/feature/branch-direct other feature stuff, direct from master with tag
4267841 | * origin/feature/branch feature changes
de1fa6d | *   origin/dev Merge branch 'master' into dev
        | |\  
        | |/  
        |/|   
a8fe481 * |   v0.2.0 origin/master Merge branch 'dev'
        |\ \  
        | |/  
3de82f8 | * v0.1.1-dev-tag dev change
        |/  
a7082b4 * v0.1.0 init

What did you expect to see?

I would expect the v0.2.0 tag to be used to generate the psuedo version, as it is the latest one

What did you see instead?

When getting the package it uses the v0.1.1-dev-tag tag to generate the psuedo version in the go.mod file

module github.com/paulbdavis/go-version-issue-consumer

go 1.12

require github.com/paulbdavis/go-version-issue v0.1.1-dev-tag.0.20190405180849-426784105212 // indirect

Getting the module on the feature/branch-direct generates a "correct" psuedo version based on v0.2.0 bumping it to v0.2.1?

module github.com/paulbdavis/go-version-issue-consumer

go 1.12

require github.com/paulbdavis/go-version-issue v0.2.1-0.20190405181040-86fe9a2567f5 // indirect
@paulbdavis

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

Also of note is that in the real repo I based the above example on I deleted the tag that go get was picking up on the dev branch and is still is using that tag somehow. I deleted the mod cache and the mod files for the module in question and it's still picking up the old tag that I deleted (deleted on the remote, not just on local)

@thepudds

This comment has been minimized.

Copy link

commented Apr 8, 2019

@paulbdavis from a triage perspective, you could try doing go get -v -x github.com/paulbdavis/go-version-issue@feature/branch.

You can then look through the git commands reported there, and then cd to the vcs cache directory listed there, and execute some of the seemingly relevant listed git commands manually.

There is a good chance the tag you see ending up in your go.mod is derived from one of the git describe --first-parent ... commands you will probably see listed. You could try manually executing that exact git command from that vcs cache directory to see what it reports.

In any event, that might give you some insight into what is happening from a git perspective, and might help triage this issue.

You can see an example of a similar investigation described in #27171 (comment), though good chance that exact set of symptoms there is not exactly what you are seeing here.

@thepudds thepudds added the modules label Apr 8, 2019

@thepudds thepudds changed the title specifying module branch writes incorrect version tag to go.mod cmd/go: specifying module branch writes incorrect version tag to go.mod Apr 8, 2019

@bcmills bcmills added this to the Go1.13 milestone Apr 10, 2019

@paulbdavis

This comment has been minimized.

Copy link
Author

commented Apr 16, 2019

Just omitting the --first-parent flag seems like it would "fix" this issue for my particular use case as it returns the version tag I would expect it to, but would no doubt break things for others.

@bcmills bcmills self-assigned this Apr 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.