{"thread":{"id":"15469","subject":"git-clone: path or ssh problem with git-upload-pack in 1.6.0?","startedAt":"2008-09-10T02:29:27Z","lastAt":"2008-09-16T15:38:54Z","messageCount":11,"participants":["Paul Johnston","Michael J Gruber","Junio C Hamano","Michael Wookey","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90306","messageId":"d3a045300809091929h18c3c447gb3d4e79131f66986@mail.gmail.com","threadId":"15469","inReplyTo":null,"subject":"git-clone: path or ssh problem with git-upload-pack in 1.6.0?","fromName":"Paul Johnston","fromEmail":"pcj127@gmail.com","sentAt":"2008-09-10T02:29:27Z","receivedAt":"2008-09-10T02:29:27Z","isPatch":false,"sender":{"key":"pcj127@gmail.com","avatar":null},"body":"I'm having trouble with git-clone and I'm wondering if there's\nsomething I'm doing wrong or something wrong with git.  Probably the\nformer, hopefully someone can set me straight.\n\nI'm an admittedly novice git user. I'm trying to clone a repository\nover ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0\ninstalled from a macports package.  This installs into /opt/local/bin.\nI also cloned git from HEAD and 'make; make install'ed into ~/bin,\nthis is the version shown below.  Either way, these are\nnonstandard/non-system-wide installation locations, and it requires\nthat my shell PATH reflect this, obviously.\n\n----------------------------------------------\n\n# About my installation\nimac:~ paul$ which git\n/Users/paul/bin/git\n\nimac:~ paul$ git --version\ngit version 1.6.0.1.285.g1070\n\nimac:~ paul$ ls /opt/local/bin/git*\n/opt/local/bin/git\n/opt/local/bin/git-upload-archive       /opt/local/bin/gitk\n/opt/local/bin/git-receive-pack         /opt/local/bin/git-upload-pack\n\nimac:~ paul$ ls ~/bin/git*\n/Users/paul/bin/git                     /Users/paul/bin/git-shell\n         /Users/paul/bin/git-upload-pack\n/Users/paul/bin/git-receive-pack        /Users/paul/bin/git-upload-archive\n\n# Make a simple reposirtory /tmp/test/.git\nimac:~ paul$ cd /tmp\nimac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git\ninit; git add README; git commit -a -m'Initial import'; cd ..\nInitialized empty Git repository in /private/tmp/test/.git/\nCreated initial commit 49c10e6: Initial import\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 README\n\n# OK, this fails expectedly\nimac:/tmp paul$ cd ~\nimac:~ paul$ git clone ssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nbash: line 1: git-upload-pack: command not found\nfatal: The remote end hung up unexpectedly\n\n# This has been killing me...  Have tried numerous variants of the\nsame with similar results...\nimac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack\nssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nremote: fatal: exec pack-objects failed.\nerror: git-upload-pack: git-pack-objects died with error.\nfatal: git-upload-pack: aborting due to possible repository corruption\non the remote side.\nremote: aborting due to possible repository corruption on the remote side.\nfatal: early EOF\nfatal: index-pack failed\n\n# Fix it with symlinks in /usr/bin\nimac:~ paul$ cd /usr/bin/\nimac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .\nimac:/usr/bin paul$ ls -al git*\nlrwxr-xr-x   1 root  wheel  18 Sep  9 19:18 git -> /opt/local/bin/git\nlrwxr-xr-x   1 root  wheel  31 Sep  9 19:18 git-receive-pack ->\n/opt/local/bin/git-receive-pack\nlrwxr-xr-x   1 root  wheel  33 Sep  9 19:18 git-upload-archive ->\n/opt/local/bin/git-upload-archive\nlrwxr-xr-x   1 root  wheel  30 Sep  9 19:18 git-upload-pack ->\n/opt/local/bin/git-upload-pack\nlrwxr-xr-x   1 root  wheel  19 Sep  9 19:18 gitk -> /opt/local/bin/gitk\n\n# And now git-clone works as expected...\nimac:/usr/bin paul$ cd\nimac:~ paul$ git clone ssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (3/3), done.\n\nimac:~ paul$ find test/\ntest/\ntest//.git\n   { file listing removed for brevity... }\ntest//README\n\n-------------------------------------------\n\nOK, great, now it works. I suspect I'm not using the --upload-pack\noption correctly or my ssh installation is suboptimal, but as I could\nfind no existing documentation on the subject, I am posting this\nmessage.  Any thoughts?\n\nPaul Johnston\n"},{"id":"90723","messageId":"d3a045300809150130w6f78edd8xf599d1c7f639b77d@mail.gmail.com","threadId":"15469","inReplyTo":"d3a045300809091929h18c3c447gb3d4e79131f66986@mail.gmail.com","subject":"git-clone: path or ssh problem with git-upload-pack in 1.6.0?","fromName":"Paul Johnston","fromEmail":"pcj127@gmail.com","sentAt":"2008-09-15T08:30:16Z","receivedAt":"2008-09-15T08:30:16Z","isPatch":false,"sender":{"key":"pcj127@gmail.com","avatar":null},"body":"I'm having trouble with git-clone and I'm wondering if there's\nsomething I'm doing wrong or something wrong with git.  Probably the\nformer, hopefully someone can set me straight.\n\nI'm an admittedly novice git user. I'm trying to clone a repository\nover ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0\ninstalled from a macports package.  This installs into /opt/local/bin.\nI also cloned git from HEAD and 'make; make install'ed into ~/bin,\nthis is the version shown below.  Either way, these are\nnonstandard/non-system-wide installation locations, and it requires\nthat my shell PATH reflect this, obviously.\n\n----------------------------------------------\n\n# About my installation\nimac:~ paul$ which git\n/Users/paul/bin/git\n\nimac:~ paul$ git --version\ngit version 1.6.0.1.285.g1070\n\nimac:~ paul$ ls /opt/local/bin/git*\n/opt/local/bin/git\n/opt/local/bin/git-upload-archive       /opt/local/bin/gitk\n/opt/local/bin/git-receive-pack         /opt/local/bin/git-upload-pack\n\nimac:~ paul$ ls ~/bin/git*\n/Users/paul/bin/git\n/Users/paul/bin/git-shell\n/Users/paul/bin/git-upload-pack\n/Users/paul/bin/git-receive-pack\n/Users/paul/bin/git-upload-archive\n\n# Make a simple reposirtory /tmp/test/.git\nimac:~ paul$ cd /tmp\nimac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git\ninit; git add README; git commit -a -m'Initial import'; cd ..\nInitialized empty Git repository in /private/tmp/test/.git/\nCreated initial commit 49c10e6: Initial import\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 README\n\n# OK, this fails expectedly\nimac:/tmp paul$ cd ~\nimac:~ paul$ git clone ssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nbash: line 1: git-upload-pack: command not found\nfatal: The remote end hung up unexpectedly\n\n# This has been killing me...  Have tried numerous variants of the\nsame with similar results...\nimac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack\nssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nremote: fatal: exec pack-objects failed.\nerror: git-upload-pack: git-pack-objects died with error.\nfatal: git-upload-pack: aborting due to possible repository corruption\non the remote side.\nremote: aborting due to possible repository corruption on the remote side.\nfatal: early EOF\nfatal: index-pack failed\n\n# Fix it with symlinks in /usr/bin\nimac:~ paul$ cd /usr/bin/\nimac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .\nimac:/usr/bin paul$ ls -al git*\nlrwxr-xr-x   1 root  wheel  18 Sep  9 19:18 git -> /opt/local/bin/git\nlrwxr-xr-x   1 root  wheel  31 Sep  9 19:18 git-receive-pack ->\n/opt/local/bin/git-receive-pack\nlrwxr-xr-x   1 root  wheel  33 Sep  9 19:18 git-upload-archive ->\n/opt/local/bin/git-upload-archive\nlrwxr-xr-x   1 root  wheel  30 Sep  9 19:18 git-upload-pack ->\n/opt/local/bin/git-upload-pack\nlrwxr-xr-x   1 root  wheel  19 Sep  9 19:18 gitk -> /opt/local/bin/gitk\n\n# And now git-clone works as expected...\nimac:/usr/bin paul$ cd\nimac:~ paul$ git clone ssh://localhost/tmp/test/.git\nInitialized empty Git repository in /Users/paul/test/.git/\nPassword:\nremote: Counting objects: 3, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (3/3), done.\n\nimac:~ paul$ find test/\ntest/\ntest//.git\n  { file listing removed for brevity... }\ntest//README\n\n-------------------------------------------\n\nOK, great, now it works. I suspect I'm not using the --upload-pack\noption correctly or my ssh installation is suboptimal, but as I could\nfind no existing documentation on the subject, I am posting this\nmessage.  Any thoughts?\n\nPaul Johnston\n"},{"id":"90753","messageId":"1221495891-12600-1-git-send-email-git@drmicha.warpmail.net","threadId":"15469","inReplyTo":"d3a045300809150130w6f78edd8xf599d1c7f639b77d@mail.gmail.com","subject":"[PATCH] help git-upload-pack find git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-09-15T16:24:51Z","receivedAt":"2008-09-15T16:24:51Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"The --upload-pack option to clone raises the expectation that finding\ngit-upload-pack on the server side is enough. But git-upload-pack needs\nto find git (for forking \"git pack-objects\") which fails if git is not\nin $PATH.\n\nThis patch makes git-upload-pack use git_set_argv0_path() so that an\nexplicitely specified path for git-upload-pack is added to the path\nwhich is used when fork()ing.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n upload-pack.c |   15 +++++++++++++++\n 1 files changed, 15 insertions(+), 0 deletions(-)\n\nThe corresponding bug was reported by Paul Johnston who wondered why \"git clone\"\nfailed when specifying --upload-pack for an out-of-$PATH installation of git.\nI'm not sure whether we should encourage this, but the --upload-pack option\nclearly gives the impression that git-upload-pack is all that is needed.\n\nI haven't looked at other server side programmes yet regarding this issue,\nbut \"git clone\" works fine with this patch in the situation where it\nwould not without.\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex e5adbc0..1fb59de 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -615,6 +615,21 @@ int main(int argc, char **argv)\n \tchar *dir;\n \tint i;\n \tint strict = 0;\n+\tconst char *cmd = argv[0] && *argv[0] ? argv[0] : \"git-upload-pack\";\n+\tchar *slash = (char *)cmd + strlen(cmd);\n+\n+\t/*\n+\t * Take the basename of argv[0] as the command\n+\t * name, and the dirname as the default exec_path\n+\t * if we don't have anything better.\n+\t */\n+\tdo\n+\t\t--slash;\n+\twhile (cmd <= slash && !is_dir_sep(*slash));\n+\tif (cmd <= slash) {\n+\t\t*slash++ = 0;\n+\t\tgit_set_argv0_path(cmd);\n+\t}\n \n \tfor (i = 1; i < argc; i++) {\n \t\tchar *arg = argv[i];\n-- \n1.6.0.1.308.gede4c\n"},{"id":"90751","messageId":"48CE8C81.2020709@fastmail.fm","threadId":"15469","inReplyTo":"d3a045300809150130w6f78edd8xf599d1c7f639b77d@mail.gmail.com","subject":"Re: git-clone: path or ssh problem with git-upload-pack in 1.6.0?","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-09-15T16:25:37Z","receivedAt":"2008-09-15T16:25:37Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Paul Johnston venit, vidit, dixit 15.09.2008 10:30:\n> I'm having trouble with git-clone and I'm wondering if there's\n> something I'm doing wrong or something wrong with git.  Probably the\n> former, hopefully someone can set me straight.\n> \n> I'm an admittedly novice git user. I'm trying to clone a repository\n> over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0\n> installed from a macports package.  This installs into /opt/local/bin.\n> I also cloned git from HEAD and 'make; make install'ed into ~/bin,\n> this is the version shown below.  Either way, these are\n> nonstandard/non-system-wide installation locations, and it requires\n> that my shell PATH reflect this, obviously.\n> \n> ----------------------------------------------\n> \n> # About my installation\n> imac:~ paul$ which git\n> /Users/paul/bin/git\n> \n> imac:~ paul$ git --version\n> git version 1.6.0.1.285.g1070\n> \n> imac:~ paul$ ls /opt/local/bin/git*\n> /opt/local/bin/git\n> /opt/local/bin/git-upload-archive       /opt/local/bin/gitk\n> /opt/local/bin/git-receive-pack         /opt/local/bin/git-upload-pack\n> \n> imac:~ paul$ ls ~/bin/git*\n> /Users/paul/bin/git\n> /Users/paul/bin/git-shell\n> /Users/paul/bin/git-upload-pack\n> /Users/paul/bin/git-receive-pack\n> /Users/paul/bin/git-upload-archive\n> \n> # Make a simple reposirtory /tmp/test/.git\n> imac:~ paul$ cd /tmp\n> imac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git\n> init; git add README; git commit -a -m'Initial import'; cd ..\n> Initialized empty Git repository in /private/tmp/test/.git/\n> Created initial commit 49c10e6: Initial import\n>  1 files changed, 1 insertions(+), 0 deletions(-)\n>  create mode 100644 README\n> \n> # OK, this fails expectedly\n> imac:/tmp paul$ cd ~\n> imac:~ paul$ git clone ssh://localhost/tmp/test/.git\n> Initialized empty Git repository in /Users/paul/test/.git/\n> Password:\n> bash: line 1: git-upload-pack: command not found\n> fatal: The remote end hung up unexpectedly\n> \n> # This has been killing me...  Have tried numerous variants of the\n> same with similar results...\n> imac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack\n> ssh://localhost/tmp/test/.git\n> Initialized empty Git repository in /Users/paul/test/.git/\n> Password:\n> remote: fatal: exec pack-objects failed.\n> error: git-upload-pack: git-pack-objects died with error.\n> fatal: git-upload-pack: aborting due to possible repository corruption\n> on the remote side.\n> remote: aborting due to possible repository corruption on the remote side.\n> fatal: early EOF\n> fatal: index-pack failed\n> \n> # Fix it with symlinks in /usr/bin\n> imac:~ paul$ cd /usr/bin/\n> imac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .\n> imac:/usr/bin paul$ ls -al git*\n> lrwxr-xr-x   1 root  wheel  18 Sep  9 19:18 git -> /opt/local/bin/git\n> lrwxr-xr-x   1 root  wheel  31 Sep  9 19:18 git-receive-pack ->\n> /opt/local/bin/git-receive-pack\n> lrwxr-xr-x   1 root  wheel  33 Sep  9 19:18 git-upload-archive ->\n> /opt/local/bin/git-upload-archive\n> lrwxr-xr-x   1 root  wheel  30 Sep  9 19:18 git-upload-pack ->\n> /opt/local/bin/git-upload-pack\n> lrwxr-xr-x   1 root  wheel  19 Sep  9 19:18 gitk -> /opt/local/bin/gitk\n> \n> # And now git-clone works as expected...\n> imac:/usr/bin paul$ cd\n> imac:~ paul$ git clone ssh://localhost/tmp/test/.git\n> Initialized empty Git repository in /Users/paul/test/.git/\n> Password:\n> remote: Counting objects: 3, done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Receiving objects: 100% (3/3), done.\n> \n> imac:~ paul$ find test/\n> test/\n> test//.git\n>   { file listing removed for brevity... }\n> test//README\n> \n> -------------------------------------------\n> \n> OK, great, now it works. I suspect I'm not using the --upload-pack\n> option correctly or my ssh installation is suboptimal, but as I could\n> find no existing documentation on the subject, I am posting this\n> message.  Any thoughts?\n\nre ssh: I'm surprised your PATH doesn't include $HOME/bin when sshing.\nThat should make everything work.\n\nre upload-pack: That indeed sounds as if upload-pack can't execute\npack-objects. I checked by moving my bin away, and clone failed. Seems\neveryone is using proper PATHS ;)\n\nIn fact, upload-pack tries to call \"git pack-objects\" and fails if it\ncan't find git. Patch upcoming...\n\nMichael\n"},{"id":"90761","messageId":"7vzlm9b3v4.fsf@gitster.siamese.dyndns.org","threadId":"15469","inReplyTo":"1221495891-12600-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-15T19:34:07Z","receivedAt":"2008-09-15T19:34:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> The corresponding bug was reported by Paul Johnston who wondered why\n> \"git clone\" failed when specifying --upload-pack for an out-of-$PATH\n> installation of git.  I'm not sure whether we should encourage this, but\n> the --upload-pack option clearly gives the impression that\n> git-upload-pack is all that is needed.\n\nAnother possibility would be to teach exec_cmd.c:setup_path() to add the\ndirectory specified by $(bindir) to PATH after we add GIT_EXEC_PATH to\nit.  That should cover the case David Miller reported, shouldn't it?\n"},{"id":"90769","messageId":"48CEC3FB.5070101@drmicha.warpmail.net","threadId":"15469","inReplyTo":"7vzlm9b3v4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-09-15T20:22:19Z","receivedAt":"2008-09-15T20:22:19Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 15.09.2008 21:34:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> The corresponding bug was reported by Paul Johnston who wondered why\n>> \"git clone\" failed when specifying --upload-pack for an out-of-$PATH\n>> installation of git.  I'm not sure whether we should encourage this, but\n>> the --upload-pack option clearly gives the impression that\n>> git-upload-pack is all that is needed.\n> \n> Another possibility would be to teach exec_cmd.c:setup_path() to add the\n> directory specified by $(bindir) to PATH after we add GIT_EXEC_PATH to\n> it.  That should cover the case David Miller reported, shouldn't it?\n\nProbably. I read that thread only after submitting my patch for\nupload-pack but suspected that other server side incarnations may suffer\nfrom the same problem.\n\nI was actually surprised that setup_path() uses argv0_path without\nsetting it, same as with argv_exec_path. I assumed this is for a good\nreason, I'm lacking the code base overview to judge this myself.\n\nIn any case, git.c sets argv0_path early, messes a bit with argv[0] and\ncalls setup_path afterwards anyways. So adding the path in setup_path()\nshould not hurt any \"git foo\" command.\n\nOne could construe situations where even that wouldn't help, because\ngit-upload-pack can't pass --exec-dir to git and they can be in\ndifferent locations - but I think that's crazy.\n\ngit.c, upload-pack.c, receive.pack.c and shell.c are the only callers.\nsetup_path() needs to get a parameter. If shell.c should profit from the\nchange then it needs to be taught how to pass an absolute path to\ndo_{generic,cvs}_cmd().\n\nSo, I guess the general approach (change setup() path and have every\ncaller profit) is OK. OK with you?\n\nMichael\n"},{"id":"90781","messageId":"d2e97e800809151539n1a074718h5c322ae757b65551@mail.gmail.com","threadId":"15469","inReplyTo":"d3a045300809091929h18c3c447gb3d4e79131f66986@mail.gmail.com","subject":"Re: git-clone: path or ssh problem with git-upload-pack in 1.6.0?","fromName":"Michael Wookey","fromEmail":"michaelwookey@gmail.com","sentAt":"2008-09-15T22:39:47Z","receivedAt":"2008-09-15T22:39:47Z","isPatch":false,"sender":{"key":"michaelwookey@gmail.com","avatar":"https://avatars.githubusercontent.com/u/19476?v=4"},"body":"> I'm having trouble with git-clone and I'm wondering if there's\n> something I'm doing wrong or something wrong with git.  Probably the\n> former, hopefully someone can set me straight.\n>\n> I'm an admittedly novice git user. I'm trying to clone a repository\n> over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0\n> installed from a macports package.  This installs into /opt/local/bin.\n> I also cloned git from HEAD and 'make; make install'ed into ~/bin,\n> this is the version shown below.  Either way, these are\n> nonstandard/non-system-wide installation locations, and it requires\n> that my shell PATH reflect this, obviously.\n\nThe following might help..\n\nhttp://marc.info/?l=git&m=121378876831164&w=2\n"},{"id":"90805","messageId":"48CF4F6A.6080604@viscovery.net","threadId":"15469","inReplyTo":"48CEC3FB.5070101@drmicha.warpmail.net","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-09-16T06:17:14Z","receivedAt":"2008-09-16T06:17:14Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Michael J Gruber schrieb:\n> I was actually surprised that setup_path() uses argv0_path without\n> setting it, same as with argv_exec_path. I assumed this is for a good\n> reason, I'm lacking the code base overview to judge this myself.\n\nIt argv_exec_path comes from git --exec-path=..., hence, git (via git.c)\nis the only caller of setup_path() that is able to set it. We can leave\nthat one out of the equation.\n\n> In any case, git.c sets argv0_path early, messes a bit with argv[0] and\n> calls setup_path afterwards anyways. So adding the path in setup_path()\n> should not hurt any \"git foo\" command.\n> \n> One could construe situations where even that wouldn't help, because\n> git-upload-pack can't pass --exec-dir to git and they can be in\n> different locations - but I think that's crazy.\n> \n> git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.\n> setup_path() needs to get a parameter. If shell.c should profit from the\n> change then it needs to be taught how to pass an absolute path to\n> do_{generic,cvs}_cmd().\n> \n> So, I guess the general approach (change setup() path and have every\n> caller profit) is OK. OK with you?\n\nHave you studied the commit message of e1464ca7bb0d (Record the command\ninvocation path early) and the context in which this commit occurs? It's\nabout relocatable git installations and how system_path() derives various\nother paths from argv[0].\n\nPlease show how you think you could change setup_path(), but keep in mind\nthat in git.c you neither can do the equivalent of git_set_argv0_path()\nlater nor setup_path() earlier.\n\n-- Hannes\n"},{"id":"90831","messageId":"48CFB183.1090205@drmicha.warpmail.net","threadId":"15469","inReplyTo":"48CF4F6A.6080604@viscovery.net","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-09-16T13:15:47Z","receivedAt":"2008-09-16T13:15:47Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 16.09.2008 08:17:\n> Michael J Gruber schrieb:\n>> I was actually surprised that setup_path() uses argv0_path without\n>> setting it, same as with argv_exec_path. I assumed this is for a good\n>> reason, I'm lacking the code base overview to judge this myself.\n> \n> It argv_exec_path comes from git --exec-path=..., hence, git (via git.c)\n> is the only caller of setup_path() that is able to set it. We can leave\n> that one out of the equation.\n> \n>> In any case, git.c sets argv0_path early, messes a bit with argv[0] and\n>> calls setup_path afterwards anyways. So adding the path in setup_path()\n>> should not hurt any \"git foo\" command.\n>>\n>> One could construe situations where even that wouldn't help, because\n>> git-upload-pack can't pass --exec-dir to git and they can be in\n>> different locations - but I think that's crazy.\n>>\n>> git.c, upload-pack.c, receive.pack.c and shell.c are the only callers.\n>> setup_path() needs to get a parameter. If shell.c should profit from the\n>> change then it needs to be taught how to pass an absolute path to\n>> do_{generic,cvs}_cmd().\n>>\n>> So, I guess the general approach (change setup() path and have every\n>> caller profit) is OK. OK with you?\n> \n> Have you studied the commit message of e1464ca7bb0d (Record the command\n> invocation path early) and the context in which this commit occurs? It's\n> about relocatable git installations and how system_path() derives various\n> other paths from argv[0].\n\nThat is what I meant by my lack of overview ;)\nI might have implemented what amounts to a revert of e1464ca7bb0d otherwise.\n\n> Please show how you think you could change setup_path(), but keep in mind\n> that in git.c you neither can do the equivalent of git_set_argv0_path()\n> later nor setup_path() earlier.\n\nWell, I'd be happy with the change in upload-pack as submitted. Junio\nsuggested the more general approach. In fact I'd prefer everyone set\ntheir path, but not everyone seems to be allowed to in their restricted\nenvironments.\n\nWhy is it that setup_path() cannot be done before commit_pager_choice()?\nWe need the pager in case list_common_cmds_help() is triggered, but why\ncan't setup_path() be before that? Not because of \"--\", really.\n\nMichael\n"},{"id":"90834","messageId":"48CFB81A.5060108@viscovery.net","threadId":"15469","inReplyTo":"48CFB183.1090205@drmicha.warpmail.net","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-09-16T13:43:54Z","receivedAt":"2008-09-16T13:43:54Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Michael J Gruber schrieb:\n> Why is it that setup_path() cannot be done before commit_pager_choice()?\n> We need the pager in case list_common_cmds_help() is triggered, but why\n> can't setup_path() be before that? Not because of \"--\", really.\n\nI think that setup_path() must be called *after* handle_options() because\nof this use-case:\n\n  $ git --exec-path=/some/where foo\n\nand git_set_argv0_path() must be called *before* handle_options() because\nof this use-case:\n\n  $ git --exec-path\n\n-- Hannes\n"},{"id":"90839","messageId":"48CFD30E.7030206@drmicha.warpmail.net","threadId":"15469","inReplyTo":"48CFB81A.5060108@viscovery.net","subject":"Re: [PATCH] help git-upload-pack find git","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-09-16T15:38:54Z","receivedAt":"2008-09-16T15:38:54Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 16.09.2008 15:43:\n> Michael J Gruber schrieb:\n>> Why is it that setup_path() cannot be done before commit_pager_choice()?\n>> We need the pager in case list_common_cmds_help() is triggered, but why\n>> can't setup_path() be before that? Not because of \"--\", really.\n> \n> I think that setup_path() must be called *after* handle_options() because\n> of this use-case:\n> \n>   $ git --exec-path=/some/where foo\n> \n> and git_set_argv0_path() must be called *before* handle_options() because\n> of this use-case:\n> \n>   $ git --exec-path\n> \n> -- Hannes\n\nTricky, I see. But still I'm getting more and more confused:\nhandle_options() calls git_exec_path() in this case, which does (unless\nthere is argv_exec_path or the variable):\nreturn system_path(GIT_EXEC_PATH)\nDuh, that comes from the Makefile, -DGIT_EXEC_PATH... Back to somewhat\nless confused state.\n\nOK, now how about\n\nA: path as submitted\n\nor\n\nB: leave git.c as is, except that setup_path(NULL) is used; have\nsetup_path(argv0path) call git_set_argv0_path() unless the arg is NULL;\ntell upload-pack etc. to stuff (other setup_path() callers) their\nargv[0] into setup_path(). Junio, is that what you meant?\n\nMichael\n"}]}