cmd/go: provide an easy way to fetch the "latest" commit version from the default branch

[hyangah]

As described in go help module-get, go get with the version suffix
@latest chooses the latest tagged release version instead of the latest
commit if there are tagged versions in the vcs.

For example, go get -m golang.org/x/text currently fetches the v0.3.0
which is more than one year-old, pre-module tagged version.

Sometimes it's useful to check the availability of the latest untagged version
(pseudo-version). Users can figure it out using the default branch name
as the suffix (e.g. go get -m golang.org/x/text@master) but the default
branch name varies depending on repos so it requires a bit of digging and
knowledge about the vcs.

[hyangah]

This will be harder or require extra care for repositories that use different branches for different versions. The module version may not exist in the source control system's default branch.

[dmitshur]

Users can figure it out using the default branch name as the suffix (e.g. go get -m golang.org/x/text@master) but the default branch name varies depending on repos so it requires a bit of digging and knowledge about the vcs.

Since it's hasn't been mentioned yet in this issue yet, I want to make the following observation.

For repositories that are known to be git, @HEAD seemingly works to fetch the latest commit of the default branch (whether that's master or another branch). This is because in git terminology, the HEAD ref of the remote repository is what determines the default branch of that repository.

For example, consider the https://github.com/rsc/go-get-default-branch repository, which has master and another-branch branches, but another-branch is the default branch:

$ go1.12beta2 list -m -versions -json github.com/rsc/go-get-default-branch@master
go: finding github.com/rsc/go-get-default-branch master
{
	"Path": "github.com/rsc/go-get-default-branch",
	"Version": "v0.0.0-20151213094453-baa4815c4965",
	"Time": "2015-12-13T09:44:53Z"
}

$ go1.12beta2 list -m -versions -json github.com/rsc/go-get-default-branch@HEAD
go: finding github.com/rsc/go-get-default-branch HEAD
{
	"Path": "github.com/rsc/go-get-default-branch",
	"Version": "v0.0.0-20151213094607-8e6902fdd036",
	"Time": "2015-12-13T09:46:07Z"
}

I don't know whether this is intended and supported, or just incidental, but it works in go1.12beta2.

Of course, HEAD is a git-specific name, so while it works to get the latest commit of the default branch of git repositories, it won't work for all other VCS types.

/cc @heschik FYI.

[hyangah]

@dmitshur Correct, the go command works as you described and picks up the latest commit from the default branch when there are no tags in the repository. That's the behavior inherited from GOPATH mode.

Once the repo starts getting tags that can be interpreted as semver or module mode tags, the default is one of the tagged version. This feature request is about exposing the functionality to pick up the latest pseudo-version easily.

[hyangah]

@dmitshur corrected me offline - @HEAD (not lower case) works in module mode with git and if we just care about picking the commit from the default branch. That's still git specific and when a user knows it's git and the user can pick the right branch and the commit.

[rsc]

I don't believe we should make any changes here. x/text is not being managed properly but that's x/text's problem not cmd/go's.

The model here is that if a publisher is tagging versioned commits, then those are the "exported" ones and everything else is "unexported". Now, they're still visible, but they're not what you are supposed to get. There is intentionally no word that means "no matter what just grab the very latest activity in the repo" across all version control systems - we don't want to encourage that behavior. There are lots of options that are specific to the version control used in the repo: @HEAD, @branchname, @commit, etc. If you are digging into unreleased commits, then I don't think it is such a burden to have to look and see what branch you really want or what version control they use.

[hyangah]

Thanks @rsc. I interpret that once a repository graduates from the pseudo-version period, and starts to use tagged release/pre-release semvers, the 'latest' version should be always one of the tagged versions.

Users who want to pick up the latest "commit" should get the version by explicitly specifying @commit or @branchname. I think that's a clear message and hope users and module owners to follow the model instead of using go get -u and expecting to pick up the 'latest commit' in the version control system.