Karthik R wrote:
Junio C Hamano wrote:
Karthik R <karthikr@xxxxxxxxxxx> writes:
+# If GIT_SSH is set, also set SVN_SSH...
+$ENV{SVN_SSH} = $ENV{GIT_SSH} if defined $ENV{GIT_SSH};
+# ... and escape \s in shell-variable on Windows
+if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ $ENV{SVN_SSH} =~ s/\\/\\\\/g if defined $ENV{SVN_SSH};
+}
+
Two questions.
- What if a user has SVN_SSH exported _and_ wants to use a different
one
from the one s/he uses for git? Naturally such a user would set both
environment variables and differently, but this seems to override the
value in SVN_SSH;
Do you mean user wants to use a different one with "git svn ...
svn+ssh://" (than the one with "git clone ssh://") ?
In this case
- defining SVN_SSH, but not GIT_SSH will still work (with this patch,
GIT_SSH overrides)
- but SVN_SSH needs to have \\s.
So unless the user already knew of this quirk, we'll only see
unescaped \s - so it *does* make sense to escape the \s (if the user
knew, then too many escaped \s still work).
- Can a user have SVN_SSH exported, on MSWin32 or msys, and use svn
outside git? If so, what does the value of SVN_SSH look like?
Does it
typically have necessary doubling of backslashes already?
With subversion for Windows, these \\s are not needed (but doesn't
cause any break). The doubling is something to do with the bash (in
msys) I think.
I was wrong... the \\ seems to be a subversion issue. This s/\\/ line in
this patch would at best be a work-around (necessary because GIT_SSH
doesn't have this bug).
http://subversion.tigris.org/issues/show_bug.cgi?id=3454 (GIT_SSH would
look like the last one in the list - and with this patch, SVN_SSH can
also look the same)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html