On Fri, May 30, 2014 at 11:12 AM, Jonathan Leonard <johana...@gmail.com> wrote: >> 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. >
The problem is that a ssh:// url can't necessarily be transformed into a correct https:// or git:// with a simple sed 's/ssh/https/' chances are other parts of the URL will need changing. Which quickly becomes non-trivial. One solution that we use at work is to use relative paths (e.g. ../code/mod1.git) in .gitmodules (assuming the submodules are all part of the same project). That way if you clone the superproject over https:// all the submodules use that too. This works well for us using local mirrors across multiple sites _and_ different protocols. Another option would be to have a policy of storing the most permissive transport in .gitmodules which makes it easy for users and puts the special config requirements on the maintainers. Both of these are obviously solutions you need to convince the maintainer(s) of the superproject to implement. Perhaps what git could do is allow multiple urls for a submodule and at git submodule init time try them in order until the fetch is successful. Or provide a mechanism to map transports, arguably this is the url.<foo>.insteadOf mechanisim that has already been suggested. -- 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
