# Clarification on the git+ssh and ssh+git schemes 5 messages from 2016-02-05 to 2016-02-05. Participants: Carlos Martín Nieto, Jeff King, Linus Torvalds, Junio C Hamano. Thread: https://gitlist.dev/t/41343 ## Carlos Martín Nieto, 2016-02-05 17:33 Subject: Clarification on the git+ssh and ssh+git schemes Message-ID: <62DF0D5B-83DF-465D-9786-A4E7DA97F2BA@dwim.me> URL: https://gitlist.dev/e/62DF0D5B-83DF-465D-9786-A4E7DA97F2BA%40dwim.me ``` Hello gits, git supports using git+ssh:// and ssh+git:// instead of ssh:// or the rsync-style format. The first two are however not documented in the git-clone manage as acceptable protocols (which is what I think of as the canonical source for what you can use). There are tests to make sure these are supported, but even the commit that allows for this (c05186cc; Support git+ssh:// and ssh+git:// URL) makes it pretty clear it’s not something that’s considered sensible. But in either case, if we’re going to support it, it should be documented. If we don’t want to support it, then we should delete the references to these formats along with the tests for this. I’m happy to write a patch going in either direction, but I’d like some input from the community as to what we want to do. Cheers, cmn ``` ## Jeff King, 2016-02-05 19:30 Subject: Re: Clarification on the git+ssh and ssh+git schemes Message-ID: <20160205193027.GC7245@sigill.intra.peff.net> URL: https://gitlist.dev/e/20160205193027.GC7245%40sigill.intra.peff.net In-Reply-To: <62DF0D5B-83DF-465D-9786-A4E7DA97F2BA@dwim.me> ``` On Fri, Feb 05, 2016 at 09:33:06AM -0800, Carlos Martín Nieto wrote: > git supports using git+ssh:// and ssh+git:// instead of ssh:// or the > rsync-style format. The first two are however not documented in the > git-clone manage as acceptable protocols (which is what I think of as > the canonical source for what you can use). There are tests to make > sure these are supported, but even the commit that allows for this > (c05186cc; Support git+ssh:// and ssh+git:// URL) makes it pretty > clear it’s not something that’s considered sensible. Hrm. I tried to find more discussion on the list, but I couldn't find any mention of git+ssh, nor of that patch. I wonder if there is a hole in my archive, or if they were done off-list for some reason. Anyway... > But in either case, if we’re going to support it, it should be > documented. If we don’t want to support it, then we should delete the > references to these formats along with the tests for this. Whether they are stupid or not (and I agree that they are), we cannot just rip them out now without warning. And given that they are probably not costing us a lot in maintenance burden to keep, I'd guess it is less effort to simply leave them in place. I suspect they were not really documented because nobody wanted to encourage their use. I don't think it would be wrong to document that they exist and are deprecated, though. > I’m happy to write a patch going in either direction, but I’d like > some input from the community as to what we want to do. I imagine your ulterior motive is also figuring out whether libgit2 needs to support them? -Peff ``` ## Linus Torvalds, 2016-02-05 19:36 Subject: Re: Clarification on the git+ssh and ssh+git schemes Message-ID: URL: https://gitlist.dev/e/CA%2B55aFyWqK0bu2V1SYagrYCBGpj0%3D2orobK2vT-KRkqpq%3Dkgtw%40mail.gmail.com In-Reply-To: <20160205193027.GC7245@sigill.intra.peff.net> ``` On Fri, Feb 5, 2016 at 11:30 AM, Jeff King wrote: > > I suspect they were not really documented because nobody wanted to > encourage their use. I don't think it would be wrong to document that > they exist and are deprecated, though. They exist because some people seemed to think that people shouldn't use "ssh://" since they thought that only ssh should use that. Which is obviously bullshit, since by that logic all the other formats should have that idiotic "git+" format too ("git+https", anybody?). It doesn't actually help anything, and it only pushes somebodys broken agenda. So there was a push for that silly thing by a couple of people, but it was always wrong. Don't even document it. Leave it in the source code as an option, and maybe add a comment about "This is stupid, but we support it for hysterical raisins". Don't add it to any real documentation. Not even as deprecated. That just validates it further. Linus ``` ## Junio C Hamano, 2016-02-05 22:11 Subject: Re: Clarification on the git+ssh and ssh+git schemes Message-ID: URL: https://gitlist.dev/e/xmqq1t8qdcyf.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Linus Torvalds writes: > On Fri, Feb 5, 2016 at 11:30 AM, Jeff King wrote: >> >> I suspect they were not really documented because nobody wanted to >> encourage their use. I don't think it would be wrong to document that >> they exist and are deprecated, though. > > They exist because some people seemed to think that people shouldn't > use "ssh://" since they thought that only ssh should use that. > > Which is obviously bullshit, since by that logic all the other formats > should have that idiotic "git+" format too ("git+https", anybody?). It > doesn't actually help anything, and it only pushes somebodys broken > agenda. > > So there was a push for that silly thing by a couple of people, but it > was always wrong. Don't even document it. "git+https://" is actually an interesting thing to think about. Those who argued that "ssh://" should only be used by ssh would say for the same reason that "http://" is OK only when Git is using the old "commit walker" aka "dumb" HTTP transport, and the modern "Git protocol over HTTP" aka "smart" HTTP should not use "http://". Which is a problematic stance to take. It would force inconvenience on our users, especially when the server side support for the modern "Git over HTTP" is done in such a way that it can co-exist with the commit walker transport. So in that sense, "git+https://" does not help anybody. I however wouldn't use such strong words like you did ;-) - If we see "hg+http://" or "svn+http://" URL, that would help people to immediately know that "git clone" would not work against them, so for us who live in Git world, "git+http:// does not buy anything (assuming that we know better than assuming all "http://" are clonable, e.g. "git clone http://nytimes.com"), it would help if others marked their non-Git URL as such. - During technical discussion inside Git circle when we need to differentiate the "smart" and "dump" HTTP transports, it may help to be able to say "git+http://" and "http://". And people who heard such a conversation may be tempted to say "git+http://" to talk to a Git repository that is known to talk the "smart HTTP" protocol. Devil's advocate mode off. > Leave it in the source code as an option, and maybe add a comment > about "This is stupid, but we support it for hysterical raisins". Sounds good. ``` ## Carlos Martín Nieto, 2016-02-05 23:59 Subject: Re: Clarification on the git+ssh and ssh+git schemes Message-ID: URL: https://gitlist.dev/e/DC6DF4A9-2BB4-432F-9893-39523E47A10B%40dwim.me In-Reply-To: ``` > On 05 Feb 2016, at 14:11, Junio C Hamano wrote: > > Linus Torvalds writes: > >> On Fri, Feb 5, 2016 at 11:30 AM, Jeff King wrote: >>> >>> I suspect they were not really documented because nobody wanted to >>> encourage their use. I don't think it would be wrong to document that >>> they exist and are deprecated, though. >> >> They exist because some people seemed to think that people shouldn't >> use "ssh://" since they thought that only ssh should use that. >> >> Which is obviously bullshit, since by that logic all the other formats >> should have that idiotic "git+" format too ("git+https", anybody?). It >> doesn't actually help anything, and it only pushes somebodys broken >> agenda. >> >> So there was a push for that silly thing by a couple of people, but it >> was always wrong. Don't even document it. > > […] > >> Leave it in the source code as an option, and maybe add a comment >> about "This is stupid, but we support it for hysterical raisins". > > Sounds good. OK then, let’s remove the reference from the manpage. As peff guessed, this query is indeed triggered by having to make a decision about whether libgit2 should support them. I suppose we’ll have to go in a similar direction. Support them because people are using them (which is why a user brought it up) but leave a comment that we don’t like it. Cheers, can ```