Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: go get doesn't work with private gitbucket repo #19766
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
gitbucket is not a hosted service, right? So we couldn't regexp it anyway, since users can run it on any hostname?
So I think the best option is for you to modify gitbucket to add the right
Let me know if I misunderstand, but I think there's nothing for us to do here so I'm going to close this. Holler if I should reopen.
I think the essence of the problem occurs when we use a git repo not in your list of public servers, we default to the regex found at line 902 in:
This regex creates the following problem as I understand it: For any git repository, if you go get domain.of.repo/repo/name.git, go tries to clone domain.of.repo/repo/name instead of name.git.
IOW, the belief by our devs is that this is incorrect behavior for the default case.
As an aside - I see more and more customers spinning up their own repos on their own hosts wherein this default behavior might come back to bite them.
P.S. We also believe there is an issue with GitBucket itself here as well:
If you try to import domain.of.repo/repo/name/deep/import, go tries to http get domain.of.repo/repo/name/deep/import, which 404s, because gitbucket serves that path at domain.of.repo/repo/name/tree/master/deep/import.
Thanks for the quick turnaround here!
Here's the issue that I'm seeing:
Please note that
From what I can tell, the default vcsPath is being matched, and the regexp is stripping the '.git' from the vcs repo. (At line 902 in vcs.go)
If your Git server is not one of the recognized ones (say, Github) and not pointed at by a custom domain using tags, then the final fallback is that we'll recognize x.git/y as meaning checkout x with git and then look at y inside the repo. Note that some Git servers (like Github) make the .git optional so that x and x.git mean the same thing, which can be a source of confusion here, but the .git in this syntax is so go get knows to use git at all, not sent to the server. Otherwise it would not be possible to use a repo that didn't end in .git.
If on your server x needs to end in .git, you need to say it twice, once for your server and once for go get:
Of course that looks awful but it's implied by the use of this fallback. In general it's far preferable to set up an HTTPS redirector to let you separate the import paths from the exact location of the git servers (for example
The fallback here predates the custom URLs. If I had it to do again I'd probably just remove the fallback entirely and require HTTPS tags.