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: provide an easy way to fetch the "latest" commit version from the default branch #29761

Closed
hyangah opened this issue Jan 16, 2019 · 6 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@hyangah
Copy link
Contributor

hyangah commented Jan 16, 2019

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.

@bcmills bcmills added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 16, 2019
@bcmills bcmills added this to the Go1.13 milestone Jan 16, 2019
@hyangah
Copy link
Contributor Author

hyangah commented Jan 17, 2019

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
Copy link
Contributor

dmitshur commented Jan 21, 2019

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
Copy link
Contributor Author

hyangah commented Jan 22, 2019

@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
Copy link
Contributor Author

hyangah commented Jan 23, 2019

@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
Copy link
Contributor

rsc commented May 15, 2019

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.

@rsc rsc closed this as completed May 15, 2019
@hyangah
Copy link
Contributor Author

hyangah commented May 15, 2019

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.

@golang golang locked and limited conversation to collaborators May 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants