git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Leonard <johanatan@gmail.com>
Cc: Jens Lehmann <Jens.Lehmann@web.de>,
	git@vger.kernel.org, John Albietz <inthecloud247@gmail.com>
Subject: Re: .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent
Date: Thu, 29 May 2014 19:56:43 -0400	[thread overview]
Message-ID: <20140529235643.GB28683@sigill.intra.peff.net> (raw)
In-Reply-To: <CA+OJ3utofb+od5uct4HF1yoQGfWgX7YTn4hPChDpC7LTFVJDYQ@mail.gmail.com>

On Thu, May 29, 2014 at 04:12:38PM -0700, Jonathan Leonard wrote:

> We are using GitHub.
> [...]
> > 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.

That's not quite true. git:// is the least privileged transport, as it
always anonymous and read-only (there ways to allow insecure pushes over
it, but GitHub does not enable them). Https is actually the most
flexible protocol, in that the same URL works of the box for both
logged-in and anonymous users (the latter assuming the repo is publicly
available). The server only prompts for credentials if necessary.

For that reason, it's a good choice for things like submodule URLs baked
into .gitmodules files.

The reasons not to are:

  1. It isn't _quite_ as efficient or robust as the regular git
     protocol, though in practice it's generally not a big deal.

  2. Pushers may prefer to authenticate with ssh keys (e.g., because
     they run ssh agent). I hope with modern credential helpers that
     logging in via http should not be a pain, either, though.

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

Using insteadOf of in your global ~/.gitconfig would make this a
one-liner per-user. So one option would be to reverse things. Put
"https" URLs into the .gitmodules file, so most people have to do
nothing, and then developers who really want to do git-over-ssh can do a
one-time:

  git config --global url.git@github.com:.insteadOf https://github.com/

-Peff

  reply	other threads:[~2014-05-29 23:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29  2:07 .gitmodules containing SSH clone URLs should fall back to HTTPS when SSH key is not valid/existent Jonathan Leonard
2014-05-29 11:35 ` Jens Lehmann
2014-05-29 18:49   ` Junio C Hamano
2014-05-29 23:12   ` Jonathan Leonard
2014-05-29 23:56     ` Jeff King [this message]
2014-05-30  4:51     ` Chris Packham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140529235643.GB28683@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=inthecloud247@gmail.com \
    --cc=johanatan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).