Support for ssh+git and git+ssh protocols #3555
Conversation
|
I'd like to see this backported to |
|
These aren't documented by git to be acceptable formats in its list of URLs in man git-clone. Additionally, I really don't like having to change external code; this especially true for the HTTP parser since we may not use our copy so this won't be supported if it's installed on the system. |
|
Hm... While they're not documented as acceptable formats, they're both supported in the git CLI. I'm having a really hard time finding out why people use this format in the first place (any amount of searching turns up basically no documentation on the format), but for whatever reason, they do and it works in the CLI so I figured that libgit2 should support it as well. The HTTP parser is definitely something that I missed as being an external dependancy. I can attempt to PR that change upstream as it is probably something that should be supported by them. It is a part of the URI Scheme Spec. Is libgit2's version pulled from https://github.com/nodejs/http-parser? |
|
People probably use it because Subversion uses Anything under |
|
Hey @carlosmn. I can't disagree with wrt it being not documented but the issue does remain that there are users that have their urls formatted like this and that git-core does support this. The commit that implements it in git-core does even say that it's stupid syntax. The bigger issue and sticking point is that there is no current way to work around this issue either. In 0.22 and below you could modify the remote url in memory so a consumer of this library could intercept a url like this and reformat it into a more sane syntax. Now in 0.23+ you'd have to load a remote, mutate its url to something more sane, save it to disk, reload the remote, mutate its url back to the craziness, and then use the remote loaded off of disk to do an operation. This seems pretty bad to me especially if you are changing a users repo in order to support a feature that they already have working in git-core. If you aren't open to explicitly supporting this in the library would you be more open to allowing a mutation of remote urls in memory again? Or some other way to work around this issue? |
|
PR for the http-parser: nodejs/http-parser#276 |
|
Wow, I didn't know that anybody used Would you mind updating your PR to include support for Additionally, I made some nitpicky comments about style - if you wouldn't mind addressing those since you're already in there. Thanks! |
| @@ -35,6 +35,8 @@ static transport_definition transports[] = { | |||
| { "file://", git_transport_local, NULL }, | |||
| #ifdef GIT_SSH | |||
| { "ssh://", git_transport_smart, &ssh_subtransport_definition }, | |||
| { "ssh+git://", git_transport_smart, &ssh_subtransport_definition }, | |||
| { "git+ssh://", git_transport_smart, &ssh_subtransport_definition }, | |||
There was a problem hiding this comment.
Could you make this (and the line above) a tab not spaces?
The parser now also supports digits, '-' and '.'. nodejs/http-parser#276
|
@ethomson Wow, great feedback, thanks! I too was disappointed to hear that people are using git+ssh and ssh+git... Seems like a weird schema to use and they add nothing to functionality on top of already existing schemas. 🤷 What can you do... I've addressed all of your comments now. Let me know if there's anything else needed. Thanks again! |
Also moving var declarations to top of blocks to support bad old compilers
…nsport ssh, ssh+git and git+ssh should all successfully build an SSH transport
a9fb382 to
813d73f
Compare
|
Is there anything else you guys need for this before pulling it in? |
|
Hi! Terribly sorry - a bunch of us are coincidentally on vacation right now. I'm just getting back to having internet; I'll take a look at this soon! Thanks for your help and your patience! |
|
Cool, thanks for the reply! |
|
So I think that Carlos wanted to double-check with the Git mailing list and either document this in git.git or remove this behavior from git.git. But if the latter, and Git removes this behavior (and I don't think that they will) then we should not merge this. So let's just make sure that this is the right thing to do. /cc @carlosmn |
|
The consensus from the list is that these were a bad idea and they never should have done it, but git has to support them for backwards compatibility. Which means we'll have to support it too; it won't be the first bad idea we do. |
|
Is there anything else that needs to be done to finish this up? |
|
Thanks for the contribution! :) |
Support for ssh+git and git+ssh protocols
This should add support for the
ssh+git://andgit+ssh://protocol schemes. The behavior is to pass directly through to thessh://protocol scheme.So, as atrocious as this is, this is a protocol that people use. From everything I can tell, they're both functionally identical to
ssh://and are treated as such in this PR. Here is an example of it being used inthe linux kernelgit core