You can still use https:// for unauthenticated access to public repos.

I know, but it's just, with git:// you know you're getting the "anonymous user" experience, so when things work for instructions or submodules or whatever you know it's not just because of your own saved credentials. If your repo is accidentally private, a git:// URL is just going to give you an error right away.

Not a big deal but just something that to my knowledge you won't be able to do going forward.

Kinda, but you could already have "saved credentials" for git:// URLs by having something like this in your ~/.config/git/config:

    [url "[email protected]:foo/bar"]
        insteadOf = git://github.com/foo/bar

Huh, I was unaware of that. But then again so are most people, I'm sure.

It's akin using HostName in an ssh config file, though with what I'd consider to be a kind of odd reversed directionality to how you define it (and obviously letting you protocol-jump like this).

Literally all of these things are also true of https://.

I really only said one thing, and I'm pretty sure it's not true of https URLs under common configurations when you've stored your credentials.

What I'm talking about is this: with a git:// URL, if you plug it into Git and that repo is private, you just get "Repository not found" immediately. With an HTTPS URL, if you're routinely using HTTPS for Git, you probably have credentials saved and you might miss that something's not publicly accessible which should be.

Further, if you do have some problem like this then the issue's arguably less clear, as the behavior of a private or simply nonexistent HTTPS repo URL for users without saved credentials is to prompt for login, which can be confusing, making a user think they need a Github account or that there's some problem with theirs.

Like I said though, it's not really a big deal.

https supports having credentials provided by various providers (and `.netrc`, for example). Which means when using https you don't know you're getting the anonymous user experience (because it's likely using credentials from other sources)

I use https solely for fetch, and ssh for push. Then the only credentials are the ssh keys. Does mean I need to edit the remote after fetching, but I'm pretty happy with that.

It will invalidate all existing git:// links to repositories hosted on Microsoft GitHub, in the name of "security".