summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 941c944)
raw | patch | inline | side by side (parent: 941c944)
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) |
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>
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 | patch | blob | history | |
git-fetch.sh | patch | blob | history |
index e624d3d0ee93c5d1618bf220ecd2d4eafddc47ca..83237562d2ba2a8891f06646ab65c0b4817e225e 100644 (file)
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to fetch from is handled
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
-f, \--force::
When `git-fetch` is used with `<rbranch>:<lbranch>`
refspec, it refuses to update the local branch
diff --git a/git-fetch.sh b/git-fetch.sh
index 4a0cb32f308742faf0f1ab4d023025ab3602ad31..d1659e2cfe78fef5bd8712edcedbf7296eb316be 100755 (executable)
--- a/git-fetch.sh
+++ b/git-fetch.sh
force=
verbose=
update_head_ok=
+exec=
while case "$#" in 0) break ;; esac
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
append=t
;;
+ -u|--u|--up|--upl|--uploa|--upload|--upload-|--upload-p|--upload-pa|\
+ --upload-pac|--upload-pack)
+ shift
+ exec="--exec=$1"
+ ;;
-f|--f|--fo|--for|--forc|--force)
force=t
;;
( : subshell because we muck with IFS
IFS=" $LF"
(
- git-fetch-pack $keep "$remote" $rref || echo failed "$remote"
+ git-fetch-pack $exec $keep "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
do