author | Michal Ostrowski <mostrows@watson.ibm.com> | |
Fri, 20 Jan 2006 18:05:24 +0000 (13:05 -0500) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Wed, 25 Jan 2006 07:17:26 +0000 (23:17 -0800) | ||
commit | 2c620a1ad1dce1e249d66ce18c7b1cce22d5d64c | |
tree | c92dc1ebdc6b9f6b27c60d31de1cc8823b009a3f | tree | snapshot |
parent | 941c9449999192e2d338ee204f4153e30ae43829 | commit | diff |
git-fetch: pass --upload-pack to fetch-pack
Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.
[jc: I have a mild suspicion that this is a broken environment (aka
sysadmin disservice). It may be legal to configure your sshd to
spawn named program without involving shell at all, and if your
sysadmin does so and you have your git programs under your home
directory, you would need something like this, but then I suspect
you would need such workaround everywhere, not just git. But we
have these options we can use to work around the issue, so there
is no strong reason not to reject this patch, either. ]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this, there is no way to specify a remote executable when
invoking git-pull/git-fetch as there is for git-clone.
[jc: I have a mild suspicion that this is a broken environment (aka
sysadmin disservice). It may be legal to configure your sshd to
spawn named program without involving shell at all, and if your
sysadmin does so and you have your git programs under your home
directory, you would need something like this, but then I suspect
you would need such workaround everywhere, not just git. But we
have these options we can use to work around the issue, so there
is no strong reason not to reject this patch, either. ]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/fetch-options.txt | diff | blob | history | |
git-fetch.sh | diff | blob | history |