Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go get fails for long paths #30623
I have a private/hidden project hosted on GitLab where the URL looks something like this:
None of these workarounds seems to work. Aside from that, there are some problems:
Having lost the
This introduced me to a different problem. Seems like
What did you do?
What did you expect to see?
What did you see instead?
Note that the half the url (
From Jan Mercl at https://groups.google.com/forum/?pli=1#!topic/golang-nuts/83hUVBGu7rA :
Seems like your git repo is just misconfigured.
Example https (wrong) config:
Make sure the url item has the right (git) protocol. Example correct config:
Above assumes you have your keys correctly registered at gitlab.
It looks like you're referring to git remote configuration. I don't think that affects how
I've been able to get it working, but it's very unintuitive and will force all developers to use ssh transport.
My goal is to fetch a go module over ssh located at
The first thing I needed to do was to rename the go module from
Then I updated my global .gitconfig to rewrite all gitlab requests over HTTPS like so:
Lastly I added
import ( "gitlab.com/my-company/my-project/my-subproject/my-important-library.git" "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/foo" "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/bar" )
import ( "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/foo" "gitlab.com/my-company/my-project/my-subproject/my-public-library/foo" // <- No ".git" postfix! )
#30304 proposes some solutions to this problem (
Proposal 1 - Make go tool chain smarter in how it selects transport for downloading dependencies
Automatically try ssh if git clone(?) over https fails. The working protocol could be cached for future requests.
Proposal 2 - Override dependency transport for the go tool chain
Introduce a way to override the transport used for different dependencies.
Example: Tool chain looks for a file named
If this file is outside the project path or not in VCS, then each developer can override this however they like.
It is important that this is configured in the go tool chain and not in git, so that we don't mess up the git tool itself.
That should not be necessary once #29888 is addressed.
To address some specific points:
Why force ssh instead of fixing HTTPS?
Any change to the
Don't you need to configure every machine that needs access to a private repo with credentials anyway?
No, in #30304 both proposals rely on the server to tell go which transport to use. Proposal 1 is a fallback solution and does not rely on the server to select a protocol.
See 26232 comment
I'm not sure if this will be an issue, but if one configure git with
Yes, I guess you're right.
It just feels wrong to setup (in my case) additional credentials for go when git is happy to work with the credentials already in place.
I think the rationale in #30304 (comment) still applies here.
In that comment, you state:
I don't see why either of those is intrinsically the case. GitHub “personal access tokens” can be authorized for repo access only. SSH keys either require a password (that is, a user interaction similar to that required by 2FA), or provide a level of security similar to a passwordless SSH key (if someone has access to your machine's SSH private key, that's just as bad as someone who has access to your machine's HTTPS access token).
Given that the practical difference is very slight, it doesn't seem worthwhile to add extra complexity to the