Hi, On Tue, 12 Feb 2008, Johannes Sixt wrote: > Jakub Narebski schrieb: > > "Elijah Newren" <newren@xxxxxxxxx> writes: > > > >> I'm pretty sure this worked before, but with git-1.5.4, when trying > >> to clone a repository via ssh from a machine that does not have git > >> installed in a standard system path, I get the following: > >> > >> $ git clone -u /home/enewren/software/install/linux/git/bin/git-upload-pack > >> ssh://enewren@remote/var/scratch/enewren/votd > >> Initialized empty Git repository in /home/newren/devel/votd/.git/ > >> remote: fatal: exec pack-objects failed. > > > > git-pull(1) > > [...] > > --upload-pack <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. > > > > The OP *did* use this option (rather, its short form, -u), see above. > > The problem is that git-upload-pack (which is not a built-in) does not > call setup_path() and so does not extend PATH to contain the special > installation location. Now, when git-upload-pack tries to exec > git-pack-objects, it fails since this is not in PATH. So, let's make git-upload-pack a builtin, no? > A quick work-around for Elijah is to add > > GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin > > to .profile on the remote host. I guess you meant .bashrc, as .profile is not sourced when using ssh transport (it does not spawn a shell) AFAIR. Ciao, Dscho - 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
