I think this is by design throughout go get. See the "remote import paths" section in go help importpath. Are you suggesting to change go get's design?

gitlab1 didn't work out well? :)

Did you consider using names like "git.yourcorp.com"? That's more idiomatic Go.

Yes. The hostname like 'git.yourcorp.com' is more idiomatic. But sometimes this is not what we can decide, especially in the internal network. And the check rule just checked that whether the hostname contains '.'. simple?

@mvdan , @bradfitz Thanks anyway!

This has also impacted my workplace. For a local server, the hostname "sw" isn't permitted but is a valid import path for a hosted gitlab server. I would like to see this check and the redirection check on the import path removed. I don't get why there are so many unnecessary checks on "go get".

If removing dot, the name will be treated as standard package. If you write hostname encoding into your /etc/hosts, go will have to git clone encoding/json with importing encoding/json.

So at present, the only way is use git clone then run go install？

Yes, but I can't say for sure if you use anothor tools.

Most tools is also use go get to get packages. It's not easy. But thanks anyway!