4 ms·

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 k

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.

duskwuff 5y ago
Literally all of these things are also true of https:// https://.
- deleted 5y ago
  [deleted]
- codys 5y ago
  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)
- zerocrates 5y ago
  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.
LukeShu 5y ago
Kinda, but you could already have "saved credentials" for git:// URLs by having something like this in your ~/.config/git/config: [url "git@github.com:foo/bar"] insteadOf = git://github.com/foo/bar
- zerocrates 5y ago
  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).
jessikat 5y ago
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.

duskwuff 5y ago

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

deleted 5y ago
[deleted]
codys 5y ago
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)
zerocrates 5y ago
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.

LukeShu 5y ago

Kinda, but you could already have "saved credentials" for git:// URLs by having something like this in your ~/.config/git/config: [url "git@github.com:foo/bar"] insteadOf = git://github.com/foo/bar

zerocrates 5y ago
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).

jessikat 5y ago

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.