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: "go get" ignores github default branch #9032

Closed
rogpeppe opened this issue Oct 31, 2014 · 11 comments
Closed

cmd/go: "go get" ignores github default branch #9032

rogpeppe opened this issue Oct 31, 2014 · 11 comments
Milestone

Comments

@rogpeppe
Copy link
Contributor

Doing "go get github.com/foo/bar" will always check out
master (assuming no tags are set) even when the default
branch in github is explicitly set to something else.

A possible fix might be to leave vcsGit.tagSyncDefault nil.
@ianlancetaylor
Copy link
Contributor

Comment 1:

Labels changed: added repo-main, release-go1.5.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@minux minux changed the title cmd/get: ignores github default branch cmd/go: "go get" ignores github default branch Dec 31, 2014
@frederich
Copy link
Contributor

The cloning works file with Go1.4 and Go1.5 ac45234. Only the branch checkout is wrong.

@frederich
Copy link
Contributor

The default branch feature is only available at Github isn't a Git feature. We can get the default branch information from Github API (https://developer.github.com/v3/repos/#get). Want we really at special Github handling to go get?

@parkr
Copy link

parkr commented Feb 19, 2015

This could potentially really slow down go get.

GitHub clones to your default branch, I believe. (Maybe I'm wrong). Just silently fail if no master is found?

@frederich
Copy link
Contributor

Sure it slow down it, and I don't want to have.

I've created a test repo with two branches b and c and no master branch. The branch b is the default Gibhub branch. Cloning over git clone works well. The b branch is checked out. Cloning over go get fails with:

  st% go get -v github.com/frederich/test2_9032
  github.com/frederich/test2_9032 (download)
  # cd /home/jf/src/github.com/frederich/test2_9032; git checkout master
  error: pathspec 'master' did not match any file(s) known to git.
  package github.com/frederich/test2_9032: exit status 1

That's okay, at the moment go get assumes master is always present.

I think we should find the right Git default branch if master is not present. But we should not use the Github API to find the default Github branch.

@rsc rsc removed the repo-main label Apr 14, 2015
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/5312 mentions this issue.

@dmitshur
Copy link
Contributor

FWIW, CL 5312 says it resolves this issue, but it's not clear to me if meant to resolve a subset, or if that was unintentional.

What it resolves is that if a default branch was not master and master was not a branch at all, previously, go get would produce an error (because it would try to execute checkout master in tagSyncDefault).

Now, that error no longer happens because tagSyncDefault was made blank.

However, go get still gets master rather than default branch specified on GitHub. I just want to confirm, that was intended, right? FWIW, I'm okay with that behavior - just want to confirm it's intended.

I'm inclined to think it's not intentional however. The commit message in CL 5312 says:

Furthermore it resolves the Github default branch issue. Changing Github default branch is effectively changing HEAD.

But that is not true (about resolving GitHub default branch issue). Here are reproduce steps:

$ go get github.com/shurcooL-legacy/go-get-default-branch
$ $GOPATH/bin/go-get-default-branch
master branch (not default branch)
$ cd $GOPATH/src/github.com/shurcooL-legacy/go-get-default-branch
$ git branch
  another-branch
* master

However, that repo is configured to have another-branch as the default branch:

https://github.com/shurcooL-legacy/go-get-default-branch

image

I'm running go version go1.5.2 darwin/amd64 and git version 2.5.4 (Apple Git-61).

(I'm only reporting this because it was on my TODO list to investigate the possible discrepancy between the commit message in this CL and actual behavior.)

@rsc
Copy link
Contributor

rsc commented Jan 4, 2016

I believe 29dc4b4 was a correct fix, but then a444da0 reintroduced a checkout master incorrectly. I think we can just remove that, but we will need to write a test. We should probably delete fixDetachedHead now too.

@rsc rsc reopened this Jan 4, 2016
@rsc rsc modified the milestones: Go1.6, Go1.5 Jan 4, 2016
@gopherbot
Copy link
Contributor

CL https://golang.org/cl/18334 mentions this issue.

@rsc rsc closed this as completed in 4220659 Jan 6, 2016
@tsuna
Copy link
Contributor

tsuna commented May 2, 2016

One side effect of the fix removing fixDetachedHead is that it's no longer possible to use go get -u -f after having run godep restore. It was really handy to be able to update dependencies (usually with go get -d -u -f -v <deps>).

It doesn't look like the removal of fixDetachedHead was necessary for this fix – @rsc was that just a cleanup you did because of the comment on that function saying "Consider removing this for Go 1.3."?

@tsuna
Copy link
Contributor

tsuna commented May 2, 2016

Just for the record (and in case anybody else lands here like I did) this is being tracked on the godep side in tools/godep#453

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants