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: revisit tag selection on 'go get' #15533

Closed
adg opened this issue May 3, 2016 · 8 comments
Closed

cmd/go: revisit tag selection on 'go get' #15533

adg opened this issue May 3, 2016 · 8 comments
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@adg
Copy link
Contributor

adg commented May 3, 2016

The docs say:

When checking out or updating a package, get looks for a branch or tag that matches the locally installed version of Go.

This is very poorly specified (if you have 1.6.2 and there's a 1.6 git tag, do you get the tagged revision?) and I'm not sure that it's useful. We should figure out whether people are using it and consider removing it entirely.

cc @rsc

@adg adg added this to the Go1.8 milestone May 3, 2016
@rsc
Copy link
Contributor

rsc commented May 3, 2016

When checking out or updating a package, get looks for a branch or tag that matches the locally installed version of Go. The most important rule is that if the local installation is running version "go1", get searches for a branch or tag named "go1". If no such version exists it retrieves the most recent version of the package.

Actually, this is the only rule.

@dmitshur
Copy link
Contributor

dmitshur commented May 4, 2016

We should figure out whether people are using it and consider removing it entirely.

At this point, I'd be very happy if it gets removed. I currently see very little use/benefit from that additional rule, but it does increase complexity (amount of things to keep in one's mind, implement in other tools, etc.). Of course, I'm open to hearing arguments why it's useful, but so far I am unaware of any.

@rsc
Copy link
Contributor

rsc commented May 4, 2016

I thought there was more here when I suggested removing it. It may be that there's not enough here to worry about. But I'd still like to see stats about how many Go repos on Github have a go1 revision (tag or branch).

@quentinmit quentinmit added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Oct 6, 2016
@mengzhuo
Copy link
Contributor

@rsc
you can try bigquery on Github.
https://bigquery.cloud.google.com/savedquery/865293014305:d80546b8c7414468ae79204288ea22e2

I had run out of quota, however the query shows only 937 files that pointing to refs that named "go1"

@dominikh
Copy link
Member

At the time of checking, there were 46670 Go repositories on GitHub listed at godoc.org, with the following stats for go1.* branches:

       1  go15
     114  go1

The repositories were obtained by go get, Go version 1.7. The branches were determined via git branch | grep go1 in each repository, then normalized to account for detached HEADs and go1 vs origin/go1.

@rsc rsc modified the milestones: Go1.9Early, Go1.8 Oct 21, 2016
@rakyll
Copy link
Contributor

rakyll commented Jan 3, 2017

According to the BigQuery's public GitHub data set, what's below are the only repos with a go1 branch. Beware that some of the items on the list are just forks.

c9s/go.matrix
xiuzhifu/Go-Redis
porridge/goexif
bdotdub/goexif
gamelost/bot3
op/goexif
ariefsam/Go-Redis
jmptrader/go.matrix
narula/ddtxn
rohanraja/go.matrix
alphazero/Go-Redis
skelterjohn/go.matrix
rodaine/goexif
kladd/goexif
rwcarlsen/goexif
doomalove/Go-Redis
gamelost/bot3server
postfix/goexif
ngaut/ddtxn

@kortschak
Copy link
Contributor

kortschak commented Jan 11, 2017

It appears that the selection of local version string is a little loose. I have a user who has found that go get for biogo/biogo fails because it tries to checkout the go1 tagged commit - this happens for go1.7.4 and go1.8rc1. I can remove the tag, but this behaviour seems counter to this #15533 (comment)"

The most important rule is that if the local installation is running version "go1", get searches for a branch or tag named "go1". If no such version exists it retrieves the most recent version of the package.

@bradfitz bradfitz modified the milestones: Go1.10Early, Go1.9Early May 3, 2017
@bradfitz bradfitz added early-in-cycle A change that should be done early in the 3 month dev cycle. and removed early-in-cycle A change that should be done early in the 3 month dev cycle. labels Jun 14, 2017
@bradfitz bradfitz modified the milestones: Go1.10Early, Go1.10 Jun 14, 2017
@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017
@rsc
Copy link
Contributor

rsc commented Apr 18, 2018

Obsoleted by modules, thank goodness.

@rsc rsc closed this as completed Apr 18, 2018
@golang golang locked and limited conversation to collaborators Apr 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

10 participants