Comment 1 by joshrickmar:

Besides not recognizing git@github.com URLs (making it impossible to use github ssh),
the recent changes to `go get` have also made it rather difficult to use public source
control websites like Github and BitBucket as mirrors and to fork packages (for the
quick PR, not a long term fork) without rewriting import paths.
For our (Conformal) company's workflow, we maintain our own git repos and use a push
hook to push all changes to the master branch to an equivalent Github repo.  Thus, we
use Github as a public mirror while maintaining complete administrative control over our
git repos.  With the `go get` change, the only method I've found to reliably work is to
change every repo to use an alternative push url for the origin remote (and we have a
lot of repos!) as well as add another internal remote so we can push and pull to
branches on our own git server.
This change has also made it more difficult to fork a git repository, keeping the same
GOPATH src path (so that import paths do not need to be rewritten) while modifying the
git remote so that changes can be pushed and pulled from a public repo (like a forked
project on Github).
I also see this change as a security loss.  Besides not recognizing git@github.com URLs
(which would allow SSH with RSA keys -- currently it can only pull from HTTPS), Github
SSH only supports RSA, whereas we would prefer to use ECDSA.  This is not an issue when
we maintain the git repo ourselves, but that isn't possible if `go get` refuses to fetch
from any place other than Github for github.com/ import paths.

Comment 2:

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

Comment 3 by marco@peereboom.us:

This basically destroys my workflow when working on my personal github projects.  I am
baffled that this change made it in tbh.

Comment 4:

There is obviously a direct conflict here between detecting packages that are not
checked out from the correct places (necessary to update ones that have moved) and
allowing "power users" to check out packages not from the correct places.
We could relax the check for the public URLs like github.com under the assumption that
they will never change, but that doesn't really solve the general problem that has been
raised, so I'd rather not make a special case.
It may be that the general problem is unsolvable and that if you're going to lie about
where you got the code then you just can't use 'go get -u'.

Status changed to Thinking.

Comment 5 by mikeydc651:

Perhaps a flag on 'go get' that says "I know what I'm doing, use the file path as the
checkout path even if the git remote origin doesn't match".

Comment 6 by dave@davec.name:

Perhaps a flag on 'go get' that says "I know what I'm doing, use the file path as the
checkout path even if the scm origin doesn't match".

Comment 7 by Lytvynov.A.V:

I might be missing something here but:
Why is using git clone with git url, as opposed to https one (without doing any changes
to git remote manually) considered incorrect by go get?
Is it expected that all repos in GOPATH are put there by go get?

Comment 8 by marco@peereboom.us:

@rsc I am not following that argument at all.
If I clone a project that I control on github, the ssh URL *is* correct.  There is
absolutely no reason to reject legitimate URLs.  Especially when using ssh since that
requires keys.
Result is that I now have to update all dependencies by hand.  This is essentially kills
go get for anyone who is a developer.  Sure if I just want run someone else's code I
like some protection, but cutting out the guys that generate said code is honestly a
terrible idea.  Go 1.3 forever I guess :(
Alternatively one can patch go forever more to remove these restrictions but I am pretty
sure we can all agree that is a pretty terrible idea as well.
Please fix go 1.4 :(

Comment 9 by marco@peereboom.us:

I forgot to add, that https://golang.org/cl/147170043/ is the diff that screws
go get up.  So if you need go get to work just revert it.

Comment 10:

Agree with marco here. The fundamental problem is that VCSs (git and bzr, at least) may
use different URLs to refer to the same repository when in write mode than general
people would use when in read mode. Having go get barfing in those cases is somewhat
unfortunate.

Comment 11:

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

Comment 12:

This issue was closed by revision ea295a4.

Status changed to Fixed.

Comment 13 by marco@peereboom.us:

Thank you!