On Wed, Sep 11, 2013 at 09:39:55PM -0700, Junio C Hamano wrote:

> If the only thing you are interested in supporting is a one-shot
> invocation, i.e. giving which identity file to use from the command
> line when you run either "git push" or "git fetch", I suspect that
> you could play with GIT_SSH environment variable, e.g.
>     GIT_SSH_IDENTITY_FILE=$HOME/.ssh/id_for_example_com git push
> and do something ugly like the attached, I suppose.

We already have GIT_SSH, so I would expect:

  GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push

to work. But sadly, GIT_SSH does not use the shell, unlike most other
configure git commands. :(

We could consider it a consistency bug and fix it, though I suspect we
may be annoying people on Windows who have spaces in their paths.

If we do go the route of adding a new variable, it would make sense to
add something for specifying arbitrary arguments, not just the identity
file. Something like GIT_SSH_ARGS would be enough, though once you start
handling splitting, dequoting, and interpreting variables, you're better
off using the shell. So maybe GIT_SSH_SHELL or similar as a preferred
version of GIT_SSH that uses the shell.

> It also crossed my mind that you could (ab)use the credential helper
> framework and ask it to return not the password but the identity
> filename, and pass it down the callchain to git_connect(), but again
> you will have to teach the credential helper as many settings as you
> would need to make in ~/.ssh/config anyway, so I find it dubious how
> it would be a win.

You could write a credential helper shell script that knows about
classes of remotes (e.g., selecting an identity file based on the
hostname), and write only a few lines to cover a large number of hosts.
For example:

  test "$1" = "get" || exit 0
  while IFS== read key val; do
    test "$key" = "host" || continue
    case "$val" in
      *.example.com) echo sshident=com_key ;;
      *.example.net) echo sshident=net_key ;;

But it feels a bit hacky to be using the credential helpers at all for
ssh connections.

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

Reply via email to