Skip to content

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

New issue
New issue
Closed
Closed
cmd/go: revisit tag selection on 'go get'#15533
Labels
FrozenDueToAgeNeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.early-in-cycleA change that should be done early in the 3 month dev cycle.
Milestone
Go1.11

Description

@adg
adg
opened on 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

Activity

  1. adg
    added this to the Go1.8 milestone on May 3, 2016

  2. rsc commented on May 3, 2016

    @rsc
    rsc
    on May 3, 2016
    Contributor

    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.

  3. dmitshur commented on May 4, 2016

    @dmitshur
    dmitshur
    on May 4, 2016
    Member

    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.

  4. rsc commented on May 4, 2016

    @rsc
    rsc
    on May 4, 2016
    Contributor

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

  5. quentinmit
    added
    NeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.
    on Oct 6, 2016

  6. mengzhuo commented on Oct 10, 2016

    @mengzhuo
    mengzhuo
    on Oct 10, 2016
    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"

  7. dominikh commented on Oct 12, 2016

    @dominikh
    dominikh
    on Oct 12, 2016
    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.

  8. rsc
    modified the milestones: Go1.9Early, Go1.8 on Oct 21, 2016

  9. rakyll commented on Jan 3, 2017

    @rakyll
    rakyll
    on Jan 3, 2017
    Contributor

    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

  10. kortschak commented on Jan 11, 2017

    @kortschak
    kortschak
    on Jan 11, 2017
    Contributor

    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.

  11. bradfitz
    modified the milestones: Go1.10Early, Go1.9Early on May 3, 2017
  12. bradfitz
    added
    early-in-cycleA change that should be done early in the 3 month dev cycle.
    and removed
    early-in-cycleA change that should be done early in the 3 month dev cycle.
    on Jun 14, 2017
  13. bradfitz
    modified the milestones: Go1.10Early, Go1.10 on Jun 14, 2017
  14. rsc
    modified the milestones: Go1.10, Go1.11 on Dec 1, 2017

  15. rsc commented on Apr 18, 2018

    @rsc
    rsc
    on Apr 18, 2018
    Contributor

    Obsoleted by modules, thank goodness.

  16. rsc
    closed this as completedon Apr 18, 2018
  17. golang
    locked and limited conversation to collaborators on Apr 18, 2019
  18. gopherbot
    added
    FrozenDueToAge
    on Apr 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsDecisionFeedback is required from experts, contributors, and/or the community before a change can be made.early-in-cycleA change that should be done early in the 3 month dev cycle.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions