Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent

From: Jonathan Leonard <johanatan@gmail.com>
Date: May 29, 2014, 23:12 UTC
Message-ID: <CA+OJ3utofb+od5uct4HF1yoQGfWgX7YTn4hPChDpC7LTFVJDYQ@mail.gmail.com>
In-Reply-To: <53871B8D.40608@web.de>

Show 5 quoted lines

> But you do not give much information about your special use
> case. I assume you have submodule repositories for which some
> developers have a valid ssh key and others don't (maybe
> because they should only have read access via https)?
>

Precisely. Specifically this is for a collection (17 or more) of GitHub-hosted projects which are maintained by only a couple of people (who have the ability to directly push via git:// or ssh://). Everyone else (including deployments and ordinary users) who clones the repo should be able to just grab the code via HTTPS and have it work.

> If that is the case you might want to look into access control
> tools like gitolite.
>

We are using GitHub.

Show 6 quoted lines

>>  Lack of this feature (or presence
>> of this bug [depending on your perspective]) is a major PITA.
>
> But why is https special? Why not fall back to the git
> protocol? Or http? (And no: I'm not serious here ;-)
>

HTTPS isn't special except in that it is the least privileged transport type (and thus should be the last resort). Whether to fallback to git:// from ssh:// or vice versa is inconsequential to this request.

Show 7 quoted lines

> After the first failed clone of the submodule at via SSH the
> developer could also just do a
>
>    git config submodule.<name>.url https://host/repo
>
> and override the URL from .gitmodules.
>

Yes, this would work. But it would be a painful manual step which we would not want to force on ordinary users (and would not want to experience ourselves either).

It should be noted that this is only really a problem as the other
options GitHub gives us are also equally (or more) painful:
a) - a unique deploy key per machine and project. (which at current
would be 17 * 3 keys all manually maintained via clicking through a
GUI [unless we wanted to automate via GitHub API (which is also a
non-trivial amount of work)]).
- or -
b) - a fake 'team' with read-only access with a single fake GitHub
account as member thereof.

I imagine this feature would be convenient for non-GitHub scenarios as well though.

--Jonathan