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

[paulbdavis]

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]

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]

@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.

[paulbdavis]

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.

[gopherbot]

Change https://golang.org/cl/174061 mentions this issue: WIP: Change RecentTag in modfetch/git to use for-each-ref instead of describe

[gopherbot]

Change https://golang.org/cl/176417 mentions this issue: cmd/go: move two vcs test repos to vcs-test.golang.org