Hi,
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.

remote: aborting due to possible repository corruption on the remote side.

fatal: early EOF

fatal: index-pack failed

fetch-pack from 'ssh://enewren@remote/var/scratch/enewren/votd' failed.
I tried doing a local clone of the same repository (worked fine), a

'git fsck -full' on the relevant repository (reported no errors), and

a few other things.  After a bit of digging, I found a really ugly

hack that works around my problem.  After recompiling git on the

remote machine with the attached patch, the clone operation succeeded.
Thanks,

Elijah

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.
--

Jakub Narebski

Poland

ShadeHawk on #git

-

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.
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.
-- Hannes
-

Hi,
I guess you meant .bashrc, as .profile is not sourced when using ssh

transport (it does not spawn a shell) AFAIR.
Ciao,

Dscho
-

As far as I can tell, setting paths in .bashrc doesn't really work (or

else I'm just doing it wrong).  If it did, I would have never hit this

bug.  Observe the difference between (feel free to replace PATH with

GIT_EXEC_PATH; same general result occurs):
  $ ssh localhost

  # Wait for connection to be made, then run

  $ echo $PATH
AND
  $ ssh localhost 'echo $PATH'
AND
  $ ssh localhost 'source .bashrc

  echo $PATH'
The first and the third give the same result, but the second gives

something different.  It is the second form that git uses, meaning

that my paths never get set up.
In my little git wrapper script, I put in some code to work around

this little issue and find git-upload-pack for the user if it can (by

ssh'ing to the machine and sourcing their .bashrc in the ssh command

if necessary; might be a hack, but it makes things nicer for me than

always specifying the -u flag).
Cheers,

Elijah

-

I had this problem as well, and the only solution I found was setting

up my .ssh/environment file.

I guess when you specify a command for ssh, it executes this command

by itself, not within a shell environment.  Usually it is bash that

sources .bashrc and .profile, so you don't get your paths set up.

Unfortunately .ssh/environment is not a scripting environment, so you

have to just specify your full path there, based on what you get when

you echo $PATH from the shell.

Also, this requires putting the following in sshd_config:
PermitUserEnvironment yes
Which, and this is the biter, is not usually a default on most

systems, as far as I can see.. so it could mean bugging the sysadmin

if it's not your machine, which is not always convenient.  Can't see

any alternative though.
Steve

-

From: Johannes Sixt <johannes.sixt@telecom.at>
Since git-upload-pack has to spawn git-pack-objects, it has to make sure

that the latter can be found in the PATH. Without this patch an attempt

to clone or pull via ssh from a server fails if the git tools are not in

the standard PATH on the server even though git clone or git pull were

invoked with --upload-pack=/path/to/git-upload-pack.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>

---
How about this (almost) one-liner instead?
-- Hannes
 upload-pack.c |    3 +++

 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c

index 7e04311..51e3ec4 100644

--- a/upload-pack.c

+++ b/upload-pack.c

@@ -620,6 +620,9 @@ int main(int argc, char **argv)
 	if (i != argc-1)

 		usage(upload_pack_usage);

+

+	setup_path(NULL);

+

 	dir = argv[i];
 	if (!enter_repo(dir, strict))

--

1.5.4.rc3.24.g25a9a
-

Hi,
I'm fine with it.
Ciao,

Dscho

-

Hi,
But I also made this:
-- snipsnap --

[PATCH] Make upload-pack a builtin
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

---

 Makefile                               |    2 +-

 upload-pack.c => builtin-upload-pack.c |    8 +++++---

 builtin.h                              |    1 +

 git.c                                  |    1 +

 4 files changed, 8 insertions(+), 4 deletions(-)

 rename upload-pack.c => builtin-upload-pack.c (98%)
diff --git a/Makefile b/Makefile

index 83c359a..1792039 100644

--- a/Makefile

+++ b/Makefile

@@ -259,7 +259,6 @@ PROGRAMS = \

 	git-show-index$X \

 	git-unpack-file$X \

 	git-update-server-info$X \

-	git-upload-pack$X \

 	git-pack-redundant$X git-var$X \

 	git-merge-tree$X git-imap-send$X \

 	git-merge-recursive$X \

@@ -392,6 +391,7 @@ BUILTIN_OBJS = \

 	builtin-update-index.o \

 	builtin-update-ref.o \

 	builtin-upload-archive.o \

+	builtin-upload-pack.o \

 	builtin-verify-pack.o \

 	builtin-verify-tag.o \

 	builtin-write-tree.o \

diff --git a/upload-pack.c b/builtin-upload-pack.c

similarity index 98%

rename from upload-pack.c

rename to builtin-upload-pack.c

index 7e04311..207754c 100644

--- a/upload-pack.c

+++ b/builtin-upload-pack.c

@@ -10,6 +10,7 @@

 #include "revision.h"

 #include "list-objects.h"

 #include "run-command.h"

+#include "builtin.h"
 static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
@@ -593,14 +594,14 @@ static void upload_pack(void)

 	}

 }
-int main(int argc, char **argv)

+int cmd_upload_pack(int argc, const char **argv, const char *prefix)

 {

 	char *dir;

 	int i;

 	int strict = 0;
 	for (i = 1; i < argc; i++) {

-		char *arg = argv[i];

+		const char *arg = argv[i];
 		if (arg[0] != '-')

 			break;

@@ -620,12 +621,13 @@ int main(int argc, char **argv)
 	if (i != argc-1)

 		usage(upload_pack_usage);

-	dir = argv[i];

+	dir = xstrdup(argv[i]);
 	if (!enter_repo(dir, strict))

 		die("'%s': unable to ch...
[ message continues ]

<snip>
I tried this patch yesterday, but it seems to suffer from the same

problem?  I had to manually apply the patch from Johannes Sixt on top

of this ("manually" since there was a trivial conflict) in order for

it to solve the problem.
Anyway, it works for me now.  Thanks for the quick fixes!
Elijah

-

Please post patches inline, not attached.
The problem you've encountered is to do with the PATH setup on the

remote end. See a previous thread

(http://thread.gmane.org/gmane.comp.version-control.git/72673/focus=72805)

for some solutions.
Dave.

-