> 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
> If that is the case you might want to look into access control
> tools like gitolite.
We are using GitHub.
>> 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
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html