Clarification on the git+ssh and ssh+git schemes

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

On Fri, Feb 05, 2016 at 09:33:06AM -0800, Carlos Martín Nieto wrote:

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...

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 imagine your ulterior motive is also figuring out whether libgit2 needs to support them?

-Peff

On Fri, Feb 5, 2016 at 11:30 AM, Jeff King <peff@peff.net> wrote:

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

Linus Torvalds <torvalds@linux-foundation.org> writes:

"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.

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