https://github.com and git@github.com equivalence

[dmitris]

I'm seeing lots of messages like:

skipping "github.com/prometheus/prometheus" because: remote URL (git@github.com:prometheus/prometheus.git) doesn't match repo URL inferred from import path (https://github.com/prometheus/prometheus)

Would it be possible for the tool to realize that they are equivalent and follow the origin git@github.com:prometheus/prometheus.git? The go tool seems to be able to handle it - I can do: go get -v -x github.com/prometheus/prometheus/... even though my origin for $GOPATH/src/github.com/prometheus/prometheus is set to git@github.com:prometheus/prometheus.git, not https://github.com/prometheus/prometheus.

[dmitshur]

This issue is subtle. Let me explain what's going on.

The reason GPS currently prints that error is not because of the difference in scheme (git@github.com:... vs https://github.com/...). It correctly compares different schemes and considers them equivalent via status.EqualRepoURLs.

The actual reason it says they're different is because of the ".git" suffix that one URL has but the other doesn't.

Related issue:

https://github.com/shurcooL/gostatus/issues/37

You can read my detailed rationale for the behavior in https://github.com/shurcooL/gostatus/issues/37#issuecomment-225336823. @mafredri came up with a nice way to quickly fix the problem in his GOPATH in https://github.com/shurcooL/gostatus/issues/37#issuecomment-225350473.

Another highly related issue is:

https://github.com/shurcooL/gostatus/issues/39

Which I think definitely played a role here, and I should try to fix it.

However, the fact that go get -u works suggests I may want to consider being less strict and also allow it. I'll look into that. However, I worry that the reason go get -u works might be because it doesn't check the remote URL at all. That would mean you could get arbitrary updates from odd remote URLs. I would feel nervous about allowing that. Anyway, I'll check, it might be that go get -u has code to ignore a ".git" suffix only.

[dmitshur]

However, I worry that the reason go get -u works might be because it doesn't check the remote URL at all. That would mean you could get arbitrary updates from odd remote URLs. I would feel nervous about allowing that.

This is sad, but go get -u will just do git pull --ff-only and it doesn't care what remote URL is. It'll happily pull from something other than what the user would get if they did git get -u import/path in an empty GOPATH.

~ $ export GOPATH=/tmp/trygopathstuffmajing
~ $ go get -u -v github.com/gorilla/mux
github.com/gorilla/mux (download)
created GOPATH=/tmp/trygopathstuffmajing; see 'go help gopath'
github.com/gorilla/mux
~ $ gocd ...mux
mux $ go list
github.com/gorilla/mux
mux $ pwd
/tmp/trygopathstuffmajing/src/github.com/gorilla/mux
mux $ git remote
origin
mux $ git remote -v
origin  https://github.com/gorilla/mux (fetch)
origin  https://github.com/gorilla/mux (push)
mux $ git remote show origin 
* remote origin
  Fetch URL: https://github.com/gorilla/mux
  Push  URL: https://github.com/gorilla/mux
  HEAD branch: master
  Remote branches:
    custom-context   tracked
    master           tracked
    matcher-refactor tracked
    subexp-fix       tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)
mux $ go list 
github.com/gorilla/mux
mux $ go get -u -v
github.com/gorilla/mux (download)
mux $ git remote set-url origin https://github.com/gorilla/mux.git
mux $ go get -u -v
github.com/gorilla/mux (download)
mux $ git remote set-url origin https://github.com/gorilla/mux.gitt
mux $ go get -u -v
github.com/gorilla/mux (download)
# cd /tmp/trygopathstuffmajing/src/github.com/gorilla/mux; git pull --ff-only
remote: Repository not found.
fatal: repository 'https://github.com/gorilla/mux.gitt/' not found
package github.com/gorilla/mux: exit status 1
mux $ git remote set-url origin https://github.com/jorisshh/mux.git
mux $ go get -u -v
github.com/gorilla/mux (download)
package ironMind/logger: unrecognized import path "ironMind/logger" (import path does not begin with hostname)
package ironMind/middleware: unrecognized import path "ironMind/middleware" (import path does not begin with hostname)
mux $ 

Edit: I'm starting to suspect this might be an unintentional bug/regression in go get -u, because it still has the -f flag:

The -f flag, valid only when -u is set, forces get -u not to verify that
each package has been checked out from the source control repository
implied by its import path. This can be useful if the source is a local fork
of the original.

I'll look more into it and see if an issue needs to be filed for Go.

[dmitshur]

I've resolved shurcooL/gostatus#39 and applied the fix to Go Package Store in 12c0a37f04d98796fc7242baa7e13cc77ce453ea.

Hopefully that helps.

[dmitshur]

I consider 12c0a37f04d98796fc7242baa7e13cc77ce453ea to have resolved this issue. I will look into go get -u behavior separately (I think it has room for improvement).

Closing, let me know if you have any further comments.