You're missing the point. You may use submodules hosted on github with Heroku, but you don't use Heroku to host that repo. You're not going to `git submodule add git@heroku.com:project`. So for the sake of argument, if we pretend that git repo hosts do need to use `git@`, I don't see a single reason why Heroku would.
> And if you're going to suggest that it should only consult users who have access to the repo, for a public project that's everybody, which makes it functionally identical to git@
Now you're confusing two things. Do you want to clone a public module as a subrepo, or allow commit access? Public repos can be cloned without identification. If you want commit access, why would project-level not work?
> Sure it does. IdentityFile is explicitly allowed to be specified multiple times for a single host, and the files will be tried in turn
Again, missing the point. If you don't specify a different host, you'll always be identified and authenticated as the first key that matches, therefore you'll only use a single account. That's why you have to use different hosts.
> And no, your own anecdotes do not constitute proof that providers often have to deal with this.
If you're not going to believe anything I say, I got nothing. Otherwise, 2 things
- I opened an issue and the response was basically "Ooooo that explains some of those tickets". They specifically mentioned issues with vagrant. - I presented this at a local meetup and someone else had put themselves in this position.
> Your work is handing out a shared public/private keypair and encouraging people to set this up as a default identity in SSH?
No. As I said, it was meant to setup the vagrant box and then not be used. By default vagrant connects using an insecure keypair.