I don't think this is true

see correction in other subthread

You have to be logged into github for the SSH clone tab to appear-- if they don't know your pubkey you can't connect using the SSH protocol.

Git can push over HTTPS, too.

aha, that wasn't previously the case, thanks for the correction

whether i'm logged in in my browser has nothing to do with whether my ssh client has access to an authorized private key

Given the number of users who are novices to both git and ssh and all the rest, and also given that the UI doesn't really have room for "teaching" (it's already a popup, so adding another popup would be pretty ugly), I think it is a fairly reasonable change.

Clearly, more people were confused by the original than outraged about the current implementation... I don't even recall the change being made.

The heuristic for Github though is that the vast majority of people visiting a repository page who aren't logged in to Github on that browser don't have an authorized private key. It makes complete sense to present only options for anonymous checkouts to anonymous users.

Long ago they used to push SSH as the "right" way to pull repositories (I still almost exclusively use SSH), but their change to recommending HTTPS instead by default is by now quite old: it's been the case for many years.

Other related things have changed more recently: Github doesn't allow git:// urls anymore (but HTTPS still allows anonymous checkouts), and when doing authenticated HTTPS, you now need to provide a token instead of your password.

The git:// protocol, to my recollection, doesn't support authentication at all. If you've ever been able to push to git:// URLs on Github, it's news to me.

i wasn't talking about git:// urls and i think that removing them was probably a good idea, for the reasons you describe, but also because they didn't have any way to stymie mitm attacks

but it seems like my original comment was incorrect in a couple of different important ways, and i appreciate people having pointed that out

This may have something to do with one of my other pet hates - projects with submodules using git:// urls. If you don't use SSH keys for github you can't do a "git submodule update --init" without first changing the submodule urls in .git/config to https:// style.

FYI if you don't want to manually convert to a SSH URL, you can use a insteadOf setting in your gitconfig to make git do it automatically: https://git-scm.com/docs/git-config#Documentation/git-config...

It seems that this has been the case for years, at least going from the (obviously logged-out) archive.org saves of the Linux repo:

https://web.archive.org/web/20180115003453/https://github.co...

i appreciate the additional correction; perhaps i was looking at github mostly while logged in previously

> embrace, extend, and extinguish is alive and well

???

you can clone Github projects and move them on every other git repository you want

if Github removed the support for git, Github would be dead in a week.

Not only because git is literally in their name, but because every programmer tool that deals with code (editors, IDEs, etc.) has embedded support for git, the protocol, not git the Github version of the protocol.

Remove interoperability and you killed the golden goose.

At MS are not that stupid.

if www browsers had removed support for ftp, browsers would have been dead in a week, in 01998

but because they waited until last year, removing that interoperability did not significantly affect their dominance as a way of accessing the internet

> but because they waited until last year

FTP died long ago as a protocol, it wasn't killed by some corporations trying to embrace and extend, but by better protocols (SFTP, SCP, HTTP(S) etc.)

also FTP created a lot of issues behind NAT

there are still ftp servers and there is still a substantial information that is only accessible through ftp, however lame the protocol design is

wrt nat i would say that nat created a lot of issues with ftp

> wrt nat i would say that nat created a lot of issues with ftp

let me rephrase it.

FTP behind NAT had a lot of issues.

But the protocol was never designed to be accessed by a WEB browser, that were limited to read only access.

The best way to access FTP is through an FTP client.

I don't necessarily agree with the new wave of browser security at all costs, like HTTPS everywhere, but FTP clients are far from being hard to find.

> there is still a substantial information that is only accessible through ftp

can you point me to an example?

I haven't encountered that problem since the end of the 90s. The only instance I can recall is upgrading the firmware of home routers/modems using TFTP.