4 ms·

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

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.

kragen 4y ago
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
- zdragnar 4y ago
  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.
- zerocrates 4y ago
  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.
  - kragen 4y ago
    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
- robinsonb5 4y ago
  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:// https:// style.
- Denvercoder9 4y ago
  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.txt-urlltbasegtinsteadOf https://git-scm.com/docs/git-config#Documentation/git-config...
- legobmw99 4y ago
  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.com/torvalds/linux https://web.archive.org/web/20180115003453/https://github.co...
  - kragen 4y ago
    i appreciate the additional correction; perhaps i was looking at github mostly while logged in previously

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.

kragen 4y ago

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

zdragnar 4y ago
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.
zerocrates 4y ago
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.
- kragen 4y ago
  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
robinsonb5 4y ago
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:// https:// style.
Denvercoder9 4y ago
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.txt-urlltbasegtinsteadOf https://git-scm.com/docs/git-config#Documentation/git-config...
legobmw99 4y ago
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.com/torvalds/linux https://web.archive.org/web/20180115003453/https://github.co...
- kragen 4y ago
  i appreciate the additional correction; perhaps i was looking at github mostly while logged in previously