Commit graph

4 commits

Author SHA1 Message Date
Joey Hess
c8a6be7eef
fix GIT_SSH_COMMAND -n parameter
It was being passed to sh, not to the command, oops. Noticed because it
broke the test suite on OSX, where sh -n silently does nothing. Would
also break on Linux when eg posh was being used as the shell; bash
ignores the -n.

This commit was supported by the NSF-funded DataLad project.
2017-03-20 14:23:19 -04:00
Joey Hess
d674fd5a69
super tricky shell command generation hack
GIT_SSH_COMMAND was not working correctly with git-annex get,
because when used in rsync -e, there were additional parameters
appended at the end, which the GIT_SSH_COMMAND should not see.

Fixed by constructing the shell command differently.

This commit was supported by the NSF-funded DataLad project.
2017-03-17 18:06:59 -04:00
Joey Hess
c9578be5b2
fix over-shell-escape
Seems I had one time too many.
2017-03-17 17:28:25 -04:00
Joey Hess
faecd73f32
Support GIT_SSH and GIT_SSH_COMMAND
They are handled close the same as they are by git. However, unlike git,
git-annex sometimes needs to pass the -n parameter when using these.

So, this has the potential for breaking some setup, and perhaps there ought
to be a ANNEX_USE_GIT_SSH=1 needed to use these. But I'd rather avoid that
if possible, so let's see if anyone complains.

Almost all places where "ssh" was run have been changed to support the env
vars. Anything still calling sshOptions does not support them. In
particular, rsync special remotes don't. Seems that annex-rsync-transport
already gives sufficient control there.

(Fixed in passing: Remote.Helper.Ssh.toRepo used to extract
remoteAnnexSshOptions and pass them to sshOptions, which was redundant
since sshOptions also extracts those.)

This commit was sponsored by Jeff Goeke-Smith on Patreon.
2017-03-17 16:20:37 -04:00