It sounds to me like the go1.4 import path checking feature is looking at the git repository to determine where it was cloned from. I wonder if a viable alternative would be to have it instead:

• Compare:
  • The import path comment // import "rsc.io/pdf"
  • Against the package directory inside $GOPATH $GOPATH/src/rsc.io/pdf

This would still have it block people from doing go get github.com/rsc/pdf -- as that would place it inside $GOPATH/src/github.com/rsc/pdf (not the same as the import comment).

I don't know enough about this to know if this is a good solution, or why testing against the git repo's remote URL was chosen (assuming I am correct on this).

Just use go get -f to bypass the check.

I'm aware I can bypass the check, and I've done so a great many times. It doesn't make the behavior any less frustrating, and it only helps when I'm running go get -u myself (e.g., any scripts I use now need to be modified to pass -f).

I think at least part of the problem is that I expect go get foo.com/a/brand/new/package to put the package in a sensible place that the rest of the Go toolchain (including go get -u) will be okay with. It's extremely surprising to me that this invariant has been broken in 1.4.

@adg it is really not practical (and I guess also not desirable) to fix all automation around go get out there to always use go get -f to ensure the tooling doesn't break for private repositories.

Would a fix for this accepted, if provided?

Please consider that github.com private repositories are a major use-case. Actually so major, that this is basically Githubs business model in a nutshell.

What would the fix look like?

On 27 January 2015 at 22:30, Ingo Oeser notifications@github.com wrote:

@adg https://github.com/adg it is really not practical (and I guess
also not desirable) to fix all automation around go get out there to
always use go get -f to ensure the tooling doesn't break for private
repositories.

Would a fix for this accepted, if provided?

Please consider that github.com private repositories are a major
use-case. Actually so major, that this is basically Githubs business model
in a nutshell.

—
Reply to this email directly or view it on GitHub
#9697 (comment).

@adg just use git config remote.origin.url instead of git remote -v. This also halves the code, as we need no parsing, just a check against supported schemes.

diff --git a/src/cmd/go/vcs.go b/src/cmd/go/vcs.go
index 1cac613..302c990 100644
--- a/src/cmd/go/vcs.go
+++ b/src/cmd/go/vcs.go
@@ -122,32 +122,21 @@ var vcsGit = &vcsCmd{
 }

 func gitRemoteRepo(vcsGit *vcsCmd, rootDir string) (remoteRepo string, err error) {
-       outb, err := vcsGit.runOutput(rootDir, "remote -v")
+       cmd := "config remote.origin.url"
+       errParse := errors.New("unable to parse output of git " + cmd)
+
+       outb, err := vcsGit.runOutput(rootDir, cmd)
        if err != nil {
                return "", err
        }
-       out := string(outb)
-
-       // Expect:
-       // origin       https://github.com/rsc/pdf (fetch)
-       // origin       https://github.com/rsc/pdf (push)
-       // use first line only.
-
-       if !strings.HasPrefix(out, "origin\t") {
-               return "", fmt.Errorf("unable to parse output of git remote -v")
-       }
-       out = strings.TrimPrefix(out, "origin\t")
-       i := strings.Index(out, "\n")
-       if i < 0 {
-               return "", fmt.Errorf("unable to parse output of git remote -v")
-       }
-       out = out[:i]
-       i = strings.LastIndex(out, " ")
-       if i < 0 {
-               return "", fmt.Errorf("unable to parse output of git remote -v")
+       repoUrl := strings.TrimSpace(string(outb))
+       for _, s := range vcsGit.scheme {
+               if strings.HasPrefix(repoUrl, s) {
+                       return repoUrl, nil
+               }
        }
-       out = out[:i]
-       return strings.TrimSpace(string(out)), nil
+       return "", errParse
+
 }

@zenazn I'm confused by this:

I think at least part of the problem is that I expect go get foo.com/a/brand/new/package to put the package in a sensible place that the rest of the Go toolchain (including go get -u) will be okay with. It's extremely surprising to me that this invariant has been broken in 1.4.

Are you saying that you can run "go get importpath" and then "go get -u importpath" and receive that error message? That shouldn't happen. I don't understand how it could happen. Or are you saying that if you run the first command with a pre-Go 1.4 go tool, and the latter with the Go 1.4 go tool, you receive the error?

@nightlyone that seems like a reasonable fix. What say you @rsc?

@adg—yeah. Run the git config line from my first message, then go get any package you like on Github, then go get -u it. Running Go 1.4.1 the whole time.

@nightlyone want to send that change as a CL?

@adg mailed out https://golang.org/cl/3504 for review

I believe that this fix is incomplete. With a .gitconfig file configured as stated in the issue, the first go get is successful, a second reports an error:

$ go get -u github.com/tools/godep
$ go get -u github.com/tools/godep
package github.com/tools/godep: github.com/tools/godep is a custom import path for https://github.com/tools/godep, but /Users/codemonkey/Projects/gopath/src/github.com/tools/godep is checked out from git@github.com:tools/godep

This creates challenges when, for example, running go get -u from a repository one is working in cause dependencies to be updated.

Please, just make it work like it did before 1.4. The change in CLI behavior breaks a lot of scripts.

@christophercurrie @ungerik Please open a new issue to discuss the specific issue you want addressed. This issue has been fixed and closed. Thanks.

@ianlancetaylor The current fix is incomplete, which is why I continued the thread here, to retain that context. However, per your request I have created #10791 to track this continuing issue.