{"thread":{"id":"36779","subject":".gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","startedAt":"2014-05-29T02:07:14Z","lastAt":"2014-05-30T04:51:20Z","messageCount":6,"participants":["Jonathan Leonard","Jens Lehmann","Junio C Hamano","Jeff King","Chris Packham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242924","messageId":"CA+OJ3uv0XqeodTCzeauUrH9FjzknBupMd5kxh+3qgyji5TwOzA@mail.gmail.com","threadId":"36779","inReplyTo":null,"subject":".gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Jonathan Leonard","fromEmail":"johanatan@gmail.com","sentAt":"2014-05-29T02:07:14Z","receivedAt":"2014-05-29T02:07:14Z","isPatch":false,"sender":{"key":"johanatan@gmail.com","avatar":null},"body":"The title pretty much says it all.  Lack of this feature (or presence\nof this bug [depending on your perspective]) is a major PITA.\n\n--Jonathan\n"},{"id":"242934","messageId":"53871B8D.40608@web.de","threadId":"36779","inReplyTo":"CA+OJ3uv0XqeodTCzeauUrH9FjzknBupMd5kxh+3qgyji5TwOzA@mail.gmail.com","subject":"Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2014-05-29T11:35:41Z","receivedAt":"2014-05-29T11:35:41Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 29.05.2014 04:07, schrieb Jonathan Leonard:\n> The title pretty much says it all.\n\nBut you do not give much information about your special use\ncase. I assume you have submodule repositories for which some\ndevelopers have a valid ssh key and others don't (maybe\nbecause they should only have read access via https)?\n\nIf that is the case you might want to look into access control\ntools like gitolite.\n\n>  Lack of this feature (or presence\n> of this bug [depending on your perspective]) is a major PITA.\n\nBut why is https special? Why not fall back to the git\nprotocol? Or http? (And no: I'm not serious here ;-)\n\nAfter the first failed clone of the submodule at via SSH the\ndeveloper could also just do a\n\n   git config submodule.<name>.url https://host/repo\n\nand override the URL from .gitmodules.\n\nBut maybe I misunderstood why you want to have a fall back?\n"},{"id":"242970","messageId":"xmqqbnugbesu.fsf@gitster.dls.corp.google.com","threadId":"36779","inReplyTo":"53871B8D.40608@web.de","subject":"Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-29T18:49:53Z","receivedAt":"2014-05-29T18:49:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 29.05.2014 04:07, schrieb Jonathan Leonard:\n>> The title pretty much says it all.\n>\n> But you do not give much information about your special use\n> case.\n\nPerhaps \"git grep insteadOf Documentation/\" is all that is needed?\n"},{"id":"242989","messageId":"CA+OJ3utofb+od5uct4HF1yoQGfWgX7YTn4hPChDpC7LTFVJDYQ@mail.gmail.com","threadId":"36779","inReplyTo":"53871B8D.40608@web.de","subject":"Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Jonathan Leonard","fromEmail":"johanatan@gmail.com","sentAt":"2014-05-29T23:12:38Z","receivedAt":"2014-05-29T23:12:38Z","isPatch":false,"sender":{"key":"johanatan@gmail.com","avatar":null},"body":"> But you do not give much information about your special use\n> case. I assume you have submodule repositories for which some\n> developers have a valid ssh key and others don't (maybe\n> because they should only have read access via https)?\n>\n\nPrecisely. Specifically this is for a collection (17 or more) of\nGitHub-hosted projects which are maintained by only a couple of people\n(who have the ability to directly push via git:// or ssh://).\nEveryone else (including deployments and ordinary users) who clones\nthe repo should be able to just grab the code via HTTPS and have it\nwork.\n\n> If that is the case you might want to look into access control\n> tools like gitolite.\n>\n\nWe are using GitHub.\n\n>>  Lack of this feature (or presence\n>> of this bug [depending on your perspective]) is a major PITA.\n>\n> But why is https special? Why not fall back to the git\n> protocol? Or http? (And no: I'm not serious here ;-)\n>\n\nHTTPS isn't special except in that it is the least privileged\ntransport type (and thus should be the last resort). Whether to\nfallback to git:// from ssh:// or vice versa is inconsequential to\nthis request.\n\n> After the first failed clone of the submodule at via SSH the\n> developer could also just do a\n>\n>    git config submodule.<name>.url https://host/repo\n>\n> and override the URL from .gitmodules.\n>\n\nYes, this would work. But it would be a painful manual step which we\nwould not want to force on ordinary users (and would not want to\nexperience ourselves either).\n\nIt should be noted that this is only really a problem as the other\noptions GitHub gives us are also equally (or more) painful:\na) - a unique deploy key per machine and project. (which at current\nwould be 17 * 3 keys all manually maintained via clicking through a\nGUI [unless we wanted to automate via GitHub API (which is also a\nnon-trivial amount of work)]).\n- or -\nb) - a fake 'team' with read-only access with a single fake GitHub\naccount as member thereof.\n\nI imagine this feature would be convenient for non-GitHub scenarios as\nwell though.\n\n--Jonathan\n"},{"id":"242994","messageId":"20140529235643.GB28683@sigill.intra.peff.net","threadId":"36779","inReplyTo":"CA+OJ3utofb+od5uct4HF1yoQGfWgX7YTn4hPChDpC7LTFVJDYQ@mail.gmail.com","subject":"Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-29T23:56:43Z","receivedAt":"2014-05-29T23:56:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 29, 2014 at 04:12:38PM -0700, Jonathan Leonard wrote:\n\n> We are using GitHub.\n> [...]\n> > But why is https special? Why not fall back to the git\n> > protocol? Or http? (And no: I'm not serious here ;-)\n> >\n> \n> HTTPS isn't special except in that it is the least privileged\n> transport type (and thus should be the last resort). Whether to\n> fallback to git:// from ssh:// or vice versa is inconsequential to\n> this request.\n\nThat's not quite true. git:// is the least privileged transport, as it\nalways anonymous and read-only (there ways to allow insecure pushes over\nit, but GitHub does not enable them). Https is actually the most\nflexible protocol, in that the same URL works of the box for both\nlogged-in and anonymous users (the latter assuming the repo is publicly\navailable). The server only prompts for credentials if necessary.\n\nFor that reason, it's a good choice for things like submodule URLs baked\ninto .gitmodules files.\n\nThe reasons not to are:\n\n  1. It isn't _quite_ as efficient or robust as the regular git\n     protocol, though in practice it's generally not a big deal.\n\n  2. Pushers may prefer to authenticate with ssh keys (e.g., because\n     they run ssh agent). I hope with modern credential helpers that\n     logging in via http should not be a pain, either, though.\n\n> > After the first failed clone of the submodule at via SSH the\n> > developer could also just do a\n> >\n> >    git config submodule.<name>.url https://host/repo\n> >\n> > and override the URL from .gitmodules.\n>\n> Yes, this would work. But it would be a painful manual step which we\n> would not want to force on ordinary users (and would not want to\n> experience ourselves either).\n\nUsing insteadOf of in your global ~/.gitconfig would make this a\none-liner per-user. So one option would be to reverse things. Put\n\"https\" URLs into the .gitmodules file, so most people have to do\nnothing, and then developers who really want to do git-over-ssh can do a\none-time:\n\n  git config --global url.git@github.com:.insteadOf https://github.com/\n\n-Peff\n"},{"id":"243003","messageId":"CAFOYHZAMEfkadzaxaYjETb5oxR25HgXZJeiPdzVGxUT-9KP+cA@mail.gmail.com","threadId":"36779","inReplyTo":"CA+OJ3utofb+od5uct4HF1yoQGfWgX7YTn4hPChDpC7LTFVJDYQ@mail.gmail.com","subject":"Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-05-30T04:51:20Z","receivedAt":"2014-05-30T04:51:20Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Fri, May 30, 2014 at 11:12 AM, Jonathan Leonard <johanatan@gmail.com> wrote:\n>> But you do not give much information about your special use\n>> case. I assume you have submodule repositories for which some\n>> developers have a valid ssh key and others don't (maybe\n>> because they should only have read access via https)?\n>>\n>\n> Precisely. Specifically this is for a collection (17 or more) of\n> GitHub-hosted projects which are maintained by only a couple of people\n> (who have the ability to directly push via git:// or ssh://).\n> Everyone else (including deployments and ordinary users) who clones\n> the repo should be able to just grab the code via HTTPS and have it\n> work.\n>\n>> If that is the case you might want to look into access control\n>> tools like gitolite.\n>>\n>\n> We are using GitHub.\n>\n>>>  Lack of this feature (or presence\n>>> of this bug [depending on your perspective]) is a major PITA.\n>>\n>> But why is https special? Why not fall back to the git\n>> protocol? Or http? (And no: I'm not serious here ;-)\n>>\n>\n> HTTPS isn't special except in that it is the least privileged\n> transport type (and thus should be the last resort). Whether to\n> fallback to git:// from ssh:// or vice versa is inconsequential to\n> this request.\n>\n\nThe problem is that a ssh:// url can't necessarily be transformed into\na correct https:// or git:// with a simple sed 's/ssh/https/' chances\nare other parts of the URL will need changing. Which quickly becomes\nnon-trivial.\n\nOne solution that we use at work is to use relative paths (e.g.\n../code/mod1.git) in .gitmodules (assuming the submodules are all part\nof the same project). That way if you clone the superproject over\nhttps:// all the submodules use that too. This works well for us using\nlocal mirrors across multiple sites _and_ different protocols.\n\nAnother option would be to have a policy of storing the most\npermissive transport in .gitmodules which makes it easy for users and\nputs the special config requirements on the maintainers.\n\nBoth of these are obviously solutions you need to convince the\nmaintainer(s) of the superproject to implement.\n\nPerhaps what git could do is allow multiple urls for a submodule and\nat git submodule init time try them in order until the fetch is\nsuccessful. Or provide a mechanism to map transports, arguably this is\nthe url.<foo>.insteadOf mechanisim that has already been suggested.\n"}]}