-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can not clone gopkg.in repo #129
Comments
Discovered at sirnewton01/ghfs#28 |
It seems that gopkg.in transparently adds ".git" to the ref discovery request, but not the following upload-pack request (I'm not entirely sure why it works with the official git client..), which confuses dgit because it expects to derive the canonical url from ref discovery |
The refsSuffix used for reference discovery appends ".git" to the repo name, while the upload pack proxying does not. This can result in a 422 response from GitHub instead of a packfile when trying to clone gopkg.in repos (ie driusan/dgit#129), making gopkg.in URLs uncloneable with some third party git clients. I'm not sure why GitHub doesn't have this issue when cloning with the official git client, but using the same base git url for both /info/refs and /git-upload-pack appears to fix the issue for dgit while not causing any noticeable regressions with real git when I tested this change locally.
After logging more information on this here is the HTTP response in question:
|
Definition of HTTP response code 422: "The request was well-formed but was unable to be followed due to semantic errors." It looks like the proxy server didn't like something about the request. Actually, the message seems to be coming back from GitHub itself. So, the proxy is altering the request in a way that GitHub doesn't like and spits out that response. I'm thinking that gopkg.in has some kind of bug or is intolerant of slightly different git implementations. |
It is a bug in their proxy, I even sent a bug fix (niemeyer/gopkg#64), but from what I can tell it's not maintained.. I'm not really sure how it works with the official git client. We might need to add a ".git" suffix to the requests in certain situations where the repo URL doesn't already end in one, but we also need to figure out which situations it's required, and make sure we don't do it in cases that will break other repos. |
Hmm, now I'm getting an error cloning that repo directly from GitHub while working on #149 |
Nm, It was just the check to switch to protocol v2. |
My understanding is that this service was provided to work around the lack of go get versioning. I suspect that the service will be going away slowly now that there are modules with semantic versioning provided directly in the "go get" command. |
As soon as we get the modules working with dgit I will probably move ghfs away from using the gpkg.in service. Maybe we should just close this? |
I'm thinking that we should close this now. Go has settled on modules for versioning dependencies. |
I think we should keep it open, I look at it as a type of git repo that isn't working and there's still code in the wild that depends on it |
If you run
go get -u gopkg.in/russross/blackfriday.v2
in fails to negotiate the pack file when doing the git clone with dgit. If you add debugging prints to dgit, it does get past the ref discovery, but then stops. If you rundgit clone https://www.github.com/russross/blackfriday
(the url that gopkg is proxying to), it's fine. The v2 branch also checks out successfully when you clone in that way.It's weird and needs investigation.
The text was updated successfully, but these errors were encountered: