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

[rogpeppe]

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]

Comment 1:

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

[frederich]

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

[frederich]

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]

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]

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.

[gopherbot]

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

[dmitshur]

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

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]

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.

[gopherbot]

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

[tsuna]

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]

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