{"thread":{"id":"12051","subject":"Unable to clone an ssh repository (with ugly installation-specific workaround)","startedAt":"2008-02-12T02:22:48Z","lastAt":"2008-02-13T14:17:20Z","messageCount":11,"participants":["Elijah Newren","David Symonds","Jakub Narebski","Johannes Sixt","Johannes Schindelin","Stephen Sinclair"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68476","messageId":"51419b2c0802111822k4600e06bp4167a09b30bf947a@mail.gmail.com","threadId":"12051","inReplyTo":null,"subject":"Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-02-12T02:22:48Z","receivedAt":"2008-02-12T02:22:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nI'm pretty sure this worked before, but with git-1.5.4, when trying to\nclone a repository via ssh from a machine that does not have git\ninstalled in a standard system path, I get the following:\n\n$ git clone -u /home/enewren/software/install/linux/git/bin/git-upload-pack\nssh://enewren@remote/var/scratch/enewren/votd\nInitialized empty Git repository in /home/newren/devel/votd/.git/\nremote: fatal: exec pack-objects failed.\nremote: aborting due to possible repository corruption on the remote side.\nfatal: early EOF\nfatal: index-pack failed\nfetch-pack from 'ssh://enewren@remote/var/scratch/enewren/votd' failed.\n\nI tried doing a local clone of the same repository (worked fine), a\n'git fsck -full' on the relevant repository (reported no errors), and\na few other things. After a bit of digging, I found a really ugly\nhack that works around my problem. After recompiling git on the\nremote machine with the attached patch, the clone operation succeeded.\n\n\nThanks,\nElijah\n\n\n--- git-1.5.4/exec_cmd.c~\t2008-02-01 21:09:01.000000000 -0700\n+++ git-1.5.4/exec_cmd.c\t2008-02-11 17:35:11.092796000 -0700\n@@ -69,7 +69,7 @@\n \tconst char *tmp;\n \n \tstrbuf_init(&cmd, 0);\n-\tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n+\tstrbuf_addf(&cmd, \"/home/enewren/software/install/linux/git/bin/git-%s\", argv[0]);\n \n \t/*\n \t * argv[0] must be the git command, but the argv array\n"},{"id":"68486","messageId":"ee77f5c20802112304j2a73c480h8add21b189d794d5@mail.gmail.com","threadId":"12051","inReplyTo":"51419b2c0802111822k4600e06bp4167a09b30bf947a@mail.gmail.com","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-02-12T07:04:35Z","receivedAt":"2008-02-12T07:04:35Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Feb 11, 2008 6:22 PM, Elijah Newren wrote:\n> Hi,\n>\n> I'm pretty sure this worked before, but with git-1.5.4, when trying to\n> clone a repository via ssh from a machine that does not have git\n> installed in a standard system path, I get the following:\n\nPlease post patches inline, not attached.\n\nThe problem you've encountered is to do with the PATH setup on the\nremote end. See a previous thread\n(http://thread.gmane.org/gmane.comp.version-control.git/72673/focus=72805)\nfor some solutions.\n\n\nDave.\n"},{"id":"68492","messageId":"m31w7iegk6.fsf@localhost.localdomain","threadId":"12051","inReplyTo":"51419b2c0802111822k4600e06bp4167a09b30bf947a@mail.gmail.com","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-12T08:16:11Z","receivedAt":"2008-02-12T08:16:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Elijah Newren\" writes:\n\n> I'm pretty sure this worked before, but with git-1.5.4, when trying to\n> clone a repository via ssh from a machine that does not have git\n> installed in a standard system path, I get the following:\n> \n> $ git clone -u /home/enewren/software/install/linux/git/bin/git-upload-pack\n> ssh://enewren@remote/var/scratch/enewren/votd\n> Initialized empty Git repository in /home/newren/devel/votd/.git/\n> remote: fatal: exec pack-objects failed.\n\ngit-pull(1)\n[...]\n --upload-pack \n When given, and the repository to fetch from is handled by\n git-fetch-pack, --exec= is passed to the command to\n specify non-default path for the command run on the other end.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"68499","messageId":"47B15ADC.8080309@viscovery.net","threadId":"12051","inReplyTo":"m31w7iegk6.fsf@localhost.localdomain","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-12T08:37:48Z","receivedAt":"2008-02-12T08:37:48Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jakub Narebski schrieb:\n> \"Elijah Newren\" writes:\n> \n>> I'm pretty sure this worked before, but with git-1.5.4, when trying to\n>> clone a repository via ssh from a machine that does not have git\n>> installed in a standard system path, I get the following:\n>>\n>> $ git clone -u /home/enewren/software/install/linux/git/bin/git-upload-pack\n>> ssh://enewren@remote/var/scratch/enewren/votd\n>> Initialized empty Git repository in /home/newren/devel/votd/.git/\n>> remote: fatal: exec pack-objects failed.\n> \n> git-pull(1)\n> [...]\n> --upload-pack \n> When given, and the repository to fetch from is handled by\n> git-fetch-pack, --exec= is passed to the command to\n> specify non-default path for the command run on the other end.\n> \n\nThe OP *did* use this option (rather, its short form, -u), see above.\n\nThe problem is that git-upload-pack (which is not a built-in) does not\ncall setup_path() and so does not extend PATH to contain the special\ninstallation location. Now, when git-upload-pack tries to exec\ngit-pack-objects, it fails since this is not in PATH.\n\nA quick work-around for Elijah is to add\n\n GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin\n\nto .profile on the remote host.\n\n-- Hannes\n"},{"id":"68506","messageId":"alpine.LSU.1.00.0802121028290.3870@racer.site","threadId":"12051","inReplyTo":"47B15ADC.8080309@viscovery.net","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-12T10:30:01Z","receivedAt":"2008-02-12T10:30:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Feb 2008, Johannes Sixt wrote:\n\n> Jakub Narebski schrieb:\n> > \"Elijah Newren\" writes:\n> > \n> >> I'm pretty sure this worked before, but with git-1.5.4, when trying \n> >> to clone a repository via ssh from a machine that does not have git \n> >> installed in a standard system path, I get the following:\n> >>\n> >> $ git clone -u /home/enewren/software/install/linux/git/bin/git-upload-pack\n> >> ssh://enewren@remote/var/scratch/enewren/votd\n> >> Initialized empty Git repository in /home/newren/devel/votd/.git/\n> >> remote: fatal: exec pack-objects failed.\n> > \n> > git-pull(1)\n> > [...]\n> > --upload-pack \n> > When given, and the repository to fetch from is handled by\n> > git-fetch-pack, --exec= is passed to the command to\n> > specify non-default path for the command run on the other end.\n> > \n> \n> The OP *did* use this option (rather, its short form, -u), see above.\n> \n> The problem is that git-upload-pack (which is not a built-in) does not\n> call setup_path() and so does not extend PATH to contain the special\n> installation location. Now, when git-upload-pack tries to exec\n> git-pack-objects, it fails since this is not in PATH.\n\nSo, let's make git-upload-pack a builtin, no?\n\n> A quick work-around for Elijah is to add\n> \n> GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin\n> \n> to .profile on the remote host.\n\nI guess you meant .bashrc, as .profile is not sourced when using ssh \ntransport (it does not spawn a shell) AFAIR.\n\nCiao,\nDscho\n"},{"id":"68508","messageId":"47B182C1.60006@viscovery.net","threadId":"12051","inReplyTo":"alpine.LSU.1.00.0802121028290.3870@racer.site","subject":"[PATCH] upload-pack: Initialize the exec-path.","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-12T11:28:01Z","receivedAt":"2008-02-12T11:28:01Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nSince git-upload-pack has to spawn git-pack-objects, it has to make sure\nthat the latter can be found in the PATH. Without this patch an attempt\nto clone or pull via ssh from a server fails if the git tools are not in\nthe standard PATH on the server even though git clone or git pull were\ninvoked with --upload-pack=/path/to/git-upload-pack.\n\nSigned-off-by: Johannes Sixt \n---\nJohannes Schindelin schrieb:\n> Hi,\n> \n> On Tue, 12 Feb 2008, Johannes Sixt wrote:\n>> The problem is that git-upload-pack (which is not a built-in) does not\n>> call setup_path() and so does not extend PATH to contain the special\n>> installation location. Now, when git-upload-pack tries to exec\n>> git-pack-objects, it fails since this is not in PATH.\n> \n> So, let's make git-upload-pack a builtin, no?\n\nHow about this (almost) one-liner instead?\n\n-- Hannes\n\n upload-pack.c | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex 7e04311..51e3ec4 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -620,6 +620,9 @@ int main(int argc, char **argv)\n\n \tif (i != argc-1)\n \t\tusage(upload_pack_usage);\n+\n+\tsetup_path(NULL);\n+\n \tdir = argv[i];\n\n \tif (!enter_repo(dir, strict))\n-- \n1.5.4.rc3.24.g25a9a\n"},{"id":"68512","messageId":"alpine.LSU.1.00.0802121149220.3870@racer.site","threadId":"12051","inReplyTo":"47B182C1.60006@viscovery.net","subject":"Re: [PATCH] upload-pack: Initialize the exec-path.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-12T11:49:42Z","receivedAt":"2008-02-12T11:49:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Feb 2008, Johannes Sixt wrote:\n\n> Johannes Schindelin schrieb:\n> > Hi,\n> > \n> > On Tue, 12 Feb 2008, Johannes Sixt wrote:\n> >> The problem is that git-upload-pack (which is not a built-in) does not\n> >> call setup_path() and so does not extend PATH to contain the special\n> >> installation location. Now, when git-upload-pack tries to exec\n> >> git-pack-objects, it fails since this is not in PATH.\n> > \n> > So, let's make git-upload-pack a builtin, no?\n> \n> How about this (almost) one-liner instead?\n\nI'm fine with it.\n\nCiao,\nDscho\n"},{"id":"68515","messageId":"alpine.LSU.1.00.0802121245140.3870@racer.site","threadId":"12051","inReplyTo":"alpine.LSU.1.00.0802121149220.3870@racer.site","subject":"Re: [PATCH] upload-pack: Initialize the exec-path.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-12T12:45:52Z","receivedAt":"2008-02-12T12:45:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 Feb 2008, Johannes Schindelin wrote:\n\n> On Tue, 12 Feb 2008, Johannes Sixt wrote:\n> \n> > Johannes Schindelin schrieb:\n> >\n> > > So, let's make git-upload-pack a builtin, no?\n> > \n> > How about this (almost) one-liner instead?\n> \n> I'm fine with it.\n\nBut I also made this:\n\n-- snipsnap --\n[PATCH] Make upload-pack a builtin\n\nSigned-off-by: Johannes Schindelin \n---\n Makefile | 2 +-\n upload-pack.c => builtin-upload-pack.c | 8 +++++---\n builtin.h | 1 +\n git.c | 1 +\n 4 files changed, 8 insertions(+), 4 deletions(-)\n rename upload-pack.c => builtin-upload-pack.c (98%)\n\ndiff --git a/Makefile b/Makefile\nindex 83c359a..1792039 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -259,7 +259,6 @@ PROGRAMS = \\\n \tgit-show-index$X \\\n \tgit-unpack-file$X \\\n \tgit-update-server-info$X \\\n-\tgit-upload-pack$X \\\n \tgit-pack-redundant$X git-var$X \\\n \tgit-merge-tree$X git-imap-send$X \\\n \tgit-merge-recursive$X \\\n@@ -392,6 +391,7 @@ BUILTIN_OBJS = \\\n \tbuiltin-update-index.o \\\n \tbuiltin-update-ref.o \\\n \tbuiltin-upload-archive.o \\\n+\tbuiltin-upload-pack.o \\\n \tbuiltin-verify-pack.o \\\n \tbuiltin-verify-tag.o \\\n \tbuiltin-write-tree.o \\\ndiff --git a/upload-pack.c b/builtin-upload-pack.c\nsimilarity index 98%\nrename from upload-pack.c\nrename to builtin-upload-pack.c\nindex 7e04311..207754c 100644\n--- a/upload-pack.c\n+++ b/builtin-upload-pack.c\n@@ -10,6 +10,7 @@\n #include \"revision.h\"\n #include \"list-objects.h\"\n #include \"run-command.h\"\n+#include \"builtin.h\"\n \n static const char upload_pack_usage[] = \"git-upload-pack [--strict] [--timeout=nn] \";\n \n@@ -593,14 +594,14 @@ static void upload_pack(void)\n \t}\n }\n \n-int main(int argc, char **argv)\n+int cmd_upload_pack(int argc, const char **argv, const char *prefix)\n {\n \tchar *dir;\n \tint i;\n \tint strict = 0;\n \n \tfor (i = 1; i < argc; i++) {\n-\t\tchar *arg = argv[i];\n+\t\tconst char *arg = argv[i];\n \n \t\tif (arg[0] != '-')\n \t\t\tbreak;\n@@ -620,12 +621,13 @@ int main(int argc, char **argv)\n \n \tif (i != argc-1)\n \t\tusage(upload_pack_usage);\n-\tdir = argv[i];\n+\tdir = xstrdup(argv[i]);\n \n \tif (!enter_repo(dir, strict))\n \t\tdie(\"'%s': unable to chdir or not a git archive\", dir);\n \tif (is_repository_shallow())\n \t\tdie(\"attempt to fetch/clone from a shallow repository\");\n \tupload_pack();\n+\tfree(dir);\n \treturn 0;\n }\ndiff --git a/builtin.h b/builtin.h\nindex 3d1628c..5e7d661 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -85,6 +85,7 @@ extern int cmd_unpack_objects(int argc, const char **argv, const char *prefix);\n extern int cmd_update_index(int argc, const char **argv, const char *prefix);\n extern int cmd_update_ref(int argc, const char **argv, const char *prefix);\n extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);\n+extern int cmd_upload_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);\n extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);\n extern int cmd_version(int argc, const char **argv, const char *prefix);\ndiff --git a/git.c b/git.c\nindex 0cb8688..f0d831c 100644\n--- a/git.c\n+++ b/git.c\n@@ -362,6 +362,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"update-index\", cmd_update_index, RUN_SETUP },\n \t\t{ \"update-ref\", cmd_update_ref, RUN_SETUP },\n \t\t{ \"upload-archive\", cmd_upload_archive },\n+\t\t{ \"upload-pack\", cmd_upload_pack },\n \t\t{ \"verify-tag\", cmd_verify_tag, RUN_SETUP },\n \t\t{ \"version\", cmd_version },\n \t\t{ \"whatchanged\", cmd_whatchanged, RUN_SETUP | USE_PAGER },\n-- \n1.5.4.1.1276.g92036\n"},{"id":"68640","messageId":"51419b2c0802130457g25892543n9db02e681d9605c5@mail.gmail.com","threadId":"12051","inReplyTo":"alpine.LSU.1.00.0802121028290.3870@racer.site","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-02-13T12:57:39Z","receivedAt":"2008-02-13T12:57:39Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Feb 12, 2008 3:30 AM, Johannes Schindelin wrote:\n> > A quick work-around for Elijah is to add\n> >\n> > GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin\n> >\n> > to .profile on the remote host.\n>\n> I guess you meant .bashrc, as .profile is not sourced when using ssh\n> transport (it does not spawn a shell) AFAIR.\n\nAs far as I can tell, setting paths in .bashrc doesn't really work (or\nelse I'm just doing it wrong). If it did, I would have never hit this\nbug. Observe the difference between (feel free to replace PATH with\nGIT_EXEC_PATH; same general result occurs):\n\n $ ssh localhost\n # Wait for connection to be made, then run\n $ echo $PATH\n\nAND\n\n $ ssh localhost 'echo $PATH'\n\nAND\n\n $ ssh localhost 'source .bashrc\n echo $PATH'\n\nThe first and the third give the same result, but the second gives\nsomething different. It is the second form that git uses, meaning\nthat my paths never get set up.\n\nIn my little git wrapper script, I put in some code to work around\nthis little issue and find git-upload-pack for the user if it can (by\nssh'ing to the machine and sourcing their .bashrc in the ssh command\nif necessary; might be a hack, but it makes things nicer for me than\nalways specifying the -u flag).\n\nCheers,\nElijah\n"},{"id":"68641","messageId":"51419b2c0802130500v9753ebeg934e2d02c9e363f7@mail.gmail.com","threadId":"12051","inReplyTo":"alpine.LSU.1.00.0802121245140.3870@racer.site","subject":"Re: [PATCH] upload-pack: Initialize the exec-path.","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-02-13T13:00:33Z","receivedAt":"2008-02-13T13:00:33Z","isPatch":true,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Feb 12, 2008 5:45 AM, Johannes Schindelin wrote:\n> On Tue, 12 Feb 2008, Johannes Schindelin wrote:\n> > On Tue, 12 Feb 2008, Johannes Sixt wrote:\n> > > Johannes Schindelin schrieb:\n> > > > So, let's make git-upload-pack a builtin, no?\n> > >\n> > > How about this (almost) one-liner instead?\n> >\n> > I'm fine with it.\n>\n> But I also made this:\n>\n> -- snipsnap --\n> [PATCH] Make upload-pack a builtin\n>\n> Signed-off-by: Johannes Schindelin \n\n\nI tried this patch yesterday, but it seems to suffer from the same\nproblem? I had to manually apply the patch from Johannes Sixt on top\nof this (\"manually\" since there was a trivial conflict) in order for\nit to solve the problem.\n\nAnyway, it works for me now. Thanks for the quick fixes!\n\nElijah\n"},{"id":"68654","messageId":"9b3e2dc20802130617m1c260c5fhb923e7a47e770f98@mail.gmail.com","threadId":"12051","inReplyTo":"51419b2c0802130457g25892543n9db02e681d9605c5@mail.gmail.com","subject":"Re: Unable to clone an ssh repository (with ugly installation-specific workaround)","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-02-13T14:17:20Z","receivedAt":"2008-02-13T14:17:20Z","isPatch":false,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"On Feb 13, 2008 7:57 AM, Elijah Newren wrote:\n> On Feb 12, 2008 3:30 AM, Johannes Schindelin wrote:\n> > > A quick work-around for Elijah is to add\n> > >\n> > > GIT_EXEC_PATH=/home/enewren/software/install/linux/git/bin\n> > >\n> > > to .profile on the remote host.\n> >\n> > I guess you meant .bashrc, as .profile is not sourced when using ssh\n> > transport (it does not spawn a shell) AFAIR.\n>\n> As far as I can tell, setting paths in .bashrc doesn't really work (or\n> else I'm just doing it wrong). If it did, I would have never hit this\n> bug. Observe the difference between (feel free to replace PATH with\n> GIT_EXEC_PATH; same general result occurs):\n>\n> $ ssh localhost\n> # Wait for connection to be made, then run\n> $ echo $PATH\n>\n> AND\n>\n> $ ssh localhost 'echo $PATH'\n>\n> AND\n>\n> $ ssh localhost 'source .bashrc\n> echo $PATH'\n>\n> The first and the third give the same result, but the second gives\n> something different. It is the second form that git uses, meaning\n> that my paths never get set up.\n\nI had this problem as well, and the only solution I found was setting\nup my .ssh/environment file.\nI guess when you specify a command for ssh, it executes this command\nby itself, not within a shell environment. Usually it is bash that\nsources .bashrc and .profile, so you don't get your paths set up.\nUnfortunately .ssh/environment is not a scripting environment, so you\nhave to just specify your full path there, based on what you get when\nyou echo $PATH from the shell.\nAlso, this requires putting the following in sshd_config:\n\nPermitUserEnvironment yes\n\nWhich, and this is the biter, is not usually a default on most\nsystems, as far as I can see.. so it could mean bugging the sysadmin\nif it's not your machine, which is not always convenient. Can't see\nany alternative though.\n\nSteve\n"}]}