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.
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.
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
--
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
